Search for a command to run...
CTO, Technical Leader. Able to clearly and effectively communicate and coordinate business, marketing, legal, IT and other processes. Worked in blockchain, payments, financial/banking, telco, pharmacy, integration, mobile, gaming, real-estate and start-up projects
No comments yet. Be the first to comment.
https://youtu.be/LmEcyQnfpDA?si=RAaITicNLVnbfR-P
Solana Frontend Crash Course presentation Solana tech videos
Often, in my projects, there is a need to somehow block access to some parts of the application to people connected from certain sanctioned or otherwise restricted jurisdictions. Doing it on the front end is usually not the best approach, but often, ...
I have been studying quite a lot about Account abstraction and ERC-4337 recently. I will point out here some resources worth reviewing: Walk through a thinking process of arriving at the current AA design, showing which problems had to be resolved a...
Innovations come to existence through different means and circumstances. Some of them start as meticulously planned inventions. Others – due to pure luck and uncontrollable external conditions. It’s never just one source that transforms promising inn...
As I wrote, one of the defining properties of smart contracts like the Ethereum smart contract is that their code is immutable . Blockchain immutability means that parties agree to the terms or “code” of the contract, that code can’t be changed by any party unilaterally.
The result of the execution of the smart contract is similarly unchangeable. Of course, that happens once the agreed-on code is executed and produces a result. The result should be objectively verified by the other party to that contract, or even by an external party. For example, this could be a regulator or observer. Only then you can be 100% certain it’s valid.
The immutability of the results of the executed smart contracts stems from what I’ve mentioned at the beginning. What’s important is the context in which the smart contract is executed: sandboxes . That means the contract is free from the influence of any external factors. An environment like that guarantees the determinism of computational results.
T he only factors that influence the result are the input data to the smart contract, and the data stored within the smart contract environment . By the latter, I’m referring to the data that was stored there when smart contract was instantiated for the first time. Or, by the previous execution iterations of the same contract. In some smart contract environments (like Ethereum) smart contracts can also communicate with each other and influence the execution of one another. However, this is still done in controlled and deterministic way.
Various implementations of smart contracts seek to leverage their benefits. Bitcoin’s smart contract language (script) is intentionally limited in complexity. The logic that can be expressed in it is very restricted. On the other hand, we have the Ethereum smart contract. The set of the operations that can be executed within the Ethereum Virtual Machine is much broader. Almost any reasonable algorithm or logic could be expressed in it, though there are still limitations on the number of operations per invocation.
Going even further, Hyperledger Fabric has no restriction on the complexity of the smart contract logic or the number of operations. That means it’s very powerful. However, it it also greatly increases the risk of node consensus divergence if that power isn’t used properly. Generally speaking, the level of expressiveness is a feature of a particular implementation. It can vary, providing different levels of security and strength for particular use cases.
It’s worth knowing the consensus doesn’t have to be immediate. Depending on the implementation, it might take around 1 hour (Bitcoin) to reach the semi-final consensus, or be almost immediate (Hyperledger Fabric). That’s despite the fact that once the consensus is reached, the smart contract execution result is provable and immutable.
Some smart contracts need to have access to structured data from the outside of their environment . In most implementations, controlled access to that data can be provided by privileged actors. They’re able to fetch the data needed at the specified time. Then, they can provably transform the data to a format that can be processed by the smart contract. Actors like that are called Oracles. They’re an inherent part of the productive smart contract ecosystem. They don’t change the other properties of the smart contracts. Oracles also work in the same sandboxed environment as the other smart contracts. Once the data is provided, it can’t be modified and is ‘provable’ forever.
If we want to execute smart contracts with the listed properties, they need to have access to some form of history inalterability. At the least, we’d need a way to prove that the history was changed and the observed results can’t be trusted any longer.
Blockchain is one technique that gives that particular feature but there’s research being done on other techniques. One of them is DAG (directed acyclic graph) where the smart contract transactions form a graph of relations (not being part of the chain of blocks). Yet another approach was undertaken by the Corda platform. There are no blocks in Corda, and transactions are exchanged directly between interested parties in the form of cryptographically signed sets of data.
Blockchain immutability brings many advantages to various industries, and is one of the features that inspire our clients to get on the blockchain. So, the Ethereum smart contract and the blockchain platform are what we deal with every day at Espeo Blockchain. That, and much more. If you’d like to leverage blockchain immutability in your project, we’re interested! Let us know in the box below.