Tezos blockchain project had a splendid start by raising $232 million with the Initial Coin Offering, obtaining second place in receiving the biggest funds among the 20 largest ICOs.

Amongst the most popular blockchain networks, such as Ethereum or Bitcoin, how was Tezos able to gain all the hype? To find out the answer, let’s take a closer look at the distinctive attributes of Tezos that have attracted hordes of supporters. 

While the blockchain that emerged during its times worked on Proof-of-Work(PoW) consensus, Tezos blockchain was innovative in using Proof-of-Stake(PoS) based consensus with a self-amending mechanism and on-chain governance. 

As a result of which, Tezos got into the limelight as the perfect alternative for building eco-friendly DeFi applications that require substantially less energy and low costs. So, how does the Tezos infrastructure equates to the flexibility in implementing upgrades much more easily?

That gets us to learn about the architectural set-up, which adds value to the Tezos.

Smart Contracts on Tezos

Smart contracts are executable contracts programmed to process the exchange of tokens between two parties without requiring either of the parties to trust the other. 

When it comes to Tezos, it is uniquely written using the Michelson programming language. Furthermore, Tezos employs formal verification to ensure the correctness of the code, which makes it more secure and reliable. 

Enumerating The Specifics of The Tezos Blockchain

The highlights of the Tezos are given here for a better understanding of its configuration and uniqueness. 

Self-amending

Tezos, which validates blocks operating on the consensus algorithm, is built-in with a self-amendable mechanism. Any amendments to the protocol, such as switching to a different consensus, modifying the reward system, adding transactions, etc., are implemented based on the on-chain voting system. 

Any minor to major changes in the Tezos economic protocol is triggered by the on-chain voting procedure. This self-amending protocol has the upper hand in avoiding the forks or splitting in the community.

On-chain governance

Tezos stands contrary to Bitcoin and Ethereum, which followed the non-formalized governance systems which led to the blockchain splits (Bitcoin Cash and Ethereum classic). 

The on-chain governance in Tezos facilitates the “Bakers”, aka Miners, to propose and cast votes on protocol upgrades. The on-chain methodology in Tezos is designed to automatically implement the upgrades in the underlying protocol’s code without going through a centralized director. 

Proof-of-stake consensus: The PoS

The PoS consensus in Tezos allows anyone to participate. In order to be a Tezos baker who validates the block and enables consensus building, the baker should possess a minimum holding of XTZ(native) tokens. 

It also adopts a method where if the user doesn’t have enough to spare for baking, they can delegate XTZ tokens to a baker with a big Tez bankroll. In turn, the rewards earned by the baker are re-distributed to the delegators. 

Exploit grounds found in Tezos smart contracts

One of the audit reports revealed errors in the message-passing architecture of Tezos smart contracts. We shall decode them here now. 

Message passing architecture

An external contract which is supposed to be called during the execution of the function is instead queued in a list of calls to be executed in the Tezos contract. 

The order found in Tezos contract is, 

• Execute a() # Next calls: [b, d]
• Execute b() # Next calls: [d, c]
• Execute d() # Next calls: [c]
• Execute c() # Next calls: []

Wherein you can see that code d() is executed before code c().

This type of execution has the possibility for two types of vulnerabilities,

Callback Authorization Bypass

The architecture of Tezos is built to prevent the contract from reading the return value of an external call using the callback function. But here, since there’s no restriction, the use of callback may lead to access control issues. 

Call Injection

It offers scope for the attacker to compromise the contract by injecting calls between a function and an external call generated. 

On the execution of the functions, the generated calls are queued in the list of calls to be executed. An attacker can gain an advantage by placing their call in the queue and executing the code between the end of the executed function and the generated calls. 

When the attacker’s call is executed, the contract’s balance or the memory of the contract goes to an invalid state, and the attacker successfully achieves the call injection. 

Precautions To Be Observed While Coding Tezos Smart Contract Using Michelson

Michelson programming language is a go-to option for writing secure contracts resistant to data leaks and fund thefts. Although the programming language is so strong, there is a list of mistakes that can appear in the contract. 

Let’s understand the common mistakes and the ways to rule out the errors.

Refunding To A List Of Contracts

This is a condition wherein a group of people’s funds are refunded at once. It occurs on accepting arbitrary contracts where a malicious user initiates such an issue. 

The possible issues from this error are a contract swallows all the gas through a series of callbacks, the ‘FAIL’ instruction is called that stops all computation, reentrancy errors and so on. 

What’s the solution?

Default accounts do not execute the code; therefore, the above issue can be sorted by creating a default account from people’s keys. Also, it can be programmed to have users pull their funds individually. 

Not Setting State Before Transfer

Reentrancy is a common hurdle in the blockchain. When the contract calls to another external contract for making transfers, the arbitrary gains an upper hand in making further transfers if the state is not updated after each transfer.

It causes multiple withdrawals of funds from the contract. 

What’s the solution?

Be careful while making calls to external contracts, and make sure that their behaviour cannot be modified. To forbid reentrancy, flag in the storage so that users cannot reenter unless they have a good reason. 

Storing Or Transferring Private Data

The data which is published could be viewed explicitly. That means the private information becomes visible to everyone when the transaction is broadcasted. This gives a chance for the malicious node in the system to manipulate the unsigned transaction by delaying or modifying them. 

What’s the solution?

Sign the transactions that contain sensitive information. Using counters to enforce transaction orders can solve the issue. 

Ensure Pro Protection To Projects Through Tezos Smart Contract Audits

Tezos built with a self-amending structure offer better scalability and reliability, but although security is always a matter of question for blockchain-based applications. The smallest of issues can cause the biggest fund loss. 

And that’s where QuillAudits takes a step forward to protect the assets from the grip of bad actors. We give them no chance of exploiting the contract as we recognize and fix those issues by conducting thorough Tezos smart contract audits. 

Have a free consultation with our experts to learn about our auditing services.