Tickets For More Efficient & Secure DeFi

‘DeFi’ became the most prominent large-scale development within the general cryptocurrency space in 2020. It is an area that is thought to have huge promise and has delivered mass financial technology innovation in the short time it has been gaining traction and media attention. It is an area that is thought to be a more mature and decentralized than the ill-fated ICO era and comes with ‘unstoppable’ smart contracts (providing there is no admin key).

Despite this huge potential, some big draw-backs have been identified. A spate of smart contract hacks and compromises have taken place, be it through poorly written smart contracts, ill thought-out governance models, interactions with other contracts, access permission manipulation, code loopholes/backdoors, or unscrupulous creators with no intention to create legitimate projects. These events are of great concern when you consider that according to DeFi Pulse around $17.87 billion USD is locked in DeFi today (4th January 2021). Many of the attacks have involved re-entrancy, which is often a huge problem for blockchains such as Ethereum, which don’t use message-passing architectures like Tezos.

In Tezos there is message passing style for interaction with smart contracts that helps to prevent re-entrancy attacks. In this system, you can’t call two smart contracts at the same time. For example, if you have two smart contracts (A and B), and you want to call smart contract (B), then you cannot call (B) in the middle of the execution of (A). You have to wait until A is over. Only then you can send a message to (B), so that (B) can do what it needs to do. This means that on Tezos, you can’t have two smart contracts being executed at the same time, like on Ethereum, which is an advantage because this helps to mitigate reentrancy attack vectors before code is deployed. So, what exactly is a reentrancy attack? 

“A reentrancy attack can occur when you create a function that makes an external call to another untrusted contract before it resolves any effects. If the attacker can control the untrusted contract, they can make a recursive call back to the original function, repeating interactions that would have otherwise not run after the effects were resolved.” – (Will Shahda, Coinmonks, 2019).

In other words, you have multiple concurrently executed contracts, whereas on Tezos a single contract is being executed at any given time. This can often make the developer experience often harder to navigate as it requires extra operations and programming. As Gabriel Alfour went on to mention:

“It’s safer than Ethereum in that you don’t have to think about two contracts being executed at the same time, but it’s harder in that you still have to emulate this functionality yourself”. An example of this would be creating two operations, instead of one meaning efficiency can still be improved on Tezos.

Recently a debate has taken place about the Tezos message passing style as it was flagged up by a smart contract audit team examining the Dexter decentralized exchange code. Although it was made clear that the message passing style helps to avoid reentrancy attacks, they mentioned this type of style and unusual ordering could lead to other vulnerabilities in the event the developer had not taken necessary precautions when writing the code. These vulnerabilities were stated as being: ‘Callback authorization bypass’ and ‘Call injection’.

The team behind the audit even suggested it might be a good idea to adopt a more standard blockchain architecture and ordering system like on Ethereum which could help developers to write code easier and help avoid such issues. The problem with this approach is that it could lead to reentrancy attacks as multiple contracts could be executed at the same time. It would also require protocol amendments to change this and a loss of some key Tezos security benefits i.e., a structure and ordering system that helps to mitigate reentrancy attack vectors before code is deployed. 

In response, several members of the community offered their thoughts on different forums that Tickets could be part of the solution.

Haochen Xie who is working on a Tezos based project called TezoSign stated on Agora:

“what might be related to this topic is the upcoming “ticket” mechanism, which could be used to help implementing the now-difficult integrity check when a CPS style re-entrance is necessary”.

Tickets was also mentioned as a possible improvement by Arthur Breitman on Reddit (see full context for image on Link):

 So, what if you could mitigate reentrancy attacks, but also be able to create decentralized applications? What if you could make the creation of decentralized applications easier and more efficient, but still keep a high security focus on the architecture? What if you could help to manage concurrency, while still maintaining high efficiency and creating an easier developer experience. Enter tickets.

Back in November 2019 contract signatures were first discussed on Tezos Agora. After this, both Arthur Breitman, Gabriel Alfour and others such as Raphaël Cauderlier from Nomadic Labs began to explore the concept. As contract signatures was explored this idea started to become known as ‘Tickets’. The project has been informed by Object Capabilities (Ocap from Cosmos), developed by famous computer scientist Mark Miller of Agoric. However, with Agoric crypto is used under the hood, whereas with Tickets linear types are used as it’s within the platform. This is more comparable to Move from Facebook. Move from Facebook is a bytecode programming language with semantics that are inspired by linear logic.

Tickets is one of the primary features of the Edo 008 protocol upgrade, along with Sapling which will enable private smart contracts on the blockchain.

Gabriel Alfour identified that one of the big problem areas that Tickets helps to alleviate with blockchains is concurrency – otherwise known as multiple computations happening at the same time. This is one of the hardest problems’ computer programmers face outside of blockchains and the issue becomes even bigger in blockchain space. This is because you not only have the underlying problem of concurrency and the need to mitigate it, you also have other risk factors associated such as:

• The immutability of smart contracts (so you can’t just patch easily).
• The high stakes of funds that can be present in cryptocurrency-related smart contracts.
• The fact that the code in many blockchain smart contracts is open-sourced.

As he states:

 “you have to manage concurrency in a very adversarial environment and where you cannot make patches”.

Tickets could be one of the first enhancements of this type and is included in the current amendment that is expected to go live in January 2021 on mainnet.

It has been stated a Tickets based system could be implemented on Ethereum without a protocol upgrade. This was mentioned on Agora by Arthur Breitman when he stated:

“A contract could store a large table of “contract signatures”. Any contract can call it and write a message on it, and pass around a handle to that message. It’s clunky and requires a bunch of callbacks but it works.”.

The key here is that it requires a lot of callbacks and is not as efficient as a version that could be placed on-chain. These call-backs not only contribute to clogging up a chain on very popular smart contract applications, but can also prove to be expensive. Having the feature be native also means that it is easier for developers to build with it. With this in mind, this particular feature upgrade is more beneficial to chains such as Tezos and Cosmos, which can upgrade layer 1 with protocol amendments.

Arthur went on to state:

“This basically replicates the experience of having assets as first-class. Coins from token contracts can be sent just like Tez, without expensive callbacks.”

This concept of taking solutions that could be smart contracts and bringing them into the core protocol has been dubbed ‘nationalization’. It is an area where Tezos has a distinct advantage over other blockchains as it can self-amend its core protocol through decentralized governance mechanisms.

There are also other benefits to bringing such features on chain too, when asked about the blockchain nationalization concept Gabriel Alfour commented:

“When we had this big table (with Tickets, which is no longer needed with the Linear tickets approach). Basically, when you are nationalized you can do a whole lot more things within the smart contract, because you have access to everything the protocol has access to. So, a basic, very concrete thing is that in a smart contract (at least in Michelson because it’s typed) you can only have a finite set of tickets, if you had implemented it within Michelson, because you have to define the types ahead of time, whereas within the protocol you can be polymorphic, which means because we implemented those in the protocol, we can support any types of tickets and we don’t need to define those types ahead of time. If people want to define new tickets with new types with new content within this, they don’t need to originate a new contract, they can just literally use the ticket feature from the protocol.

Later, imagine that we want to make Tickets smarter on the block level (i.e. adding support for TZ1 accounts among other things) it will be very easy to do so as opposed to a smart contract because if you had this as a smart contract, I’m not even talking about the efficiency things before intermediating yourself with any of those features you expose this feature to all smart contracts. So, for a feature that is as pervasive and critical as this, it’s much better to have it within a protocol, you can have it interact with all of the other features you don’t necessarily want to expose in this smart contract and things like this, so it just makes so much more sense to nationalize it. 

Taking critical and generic blockchain features to the protocol level is something that interests Gabriel Alfour:

“The thing that I care about. Before coming to Tezos I wanted to make my own blockchain and my idea for a blockchain back then, it was like 3 years ago or something was to basically have the minimal blockchain needed, to make developing layer 2s as easy as possible. So, if it was only up to me, my priorities for Tezos right now would be a lot of efficiency improvements in all areas, smart contracts, consensus and things like this, so that later I could nationalize layer 2s. So, I could have layer 2 support from the protocol directly, which would be much better than smart contracts because I can use any crypto library, ZKLibrary I could use anything that I wanted. I could write it in OCaml. which would be much easier and safer than writing it in Michelson and things like this. So, for me that would be one of the next things I would want to have.

Personally, I’m more on the side of nationalizing assets, representations of assets, things like tokens and things like this, Tickets flows directly in that direction.  The main idea being that those are things that are very critical features of all blockchains right now, so it makes sense for them to be done in a better programming environment than the smart contract one, so that you have all the control that you want with the very fine control. A big benefit of blockchains is that you can nationalize things.

Like you could compare this to cloud platforms, this is another place where you can execute arbitrary code and in the cloud platform you have no standardization at all, so if I created an app and someone else created an app, by default they would be totally incompatible. Even though they are very basic features that are in cloud apps that are shared everywhere, let’s say messaging. But by default, all of those cloud apps (messaging) won’t be compatible.

A thing that would make sense there would be to nationalize ‘messaging’ in cloud apps, it’s the same thing in blockchain. All apps will need a representation for assets, so we can let each app define their own representation and have them be incompatible by default, or try and have them develop standards on top of each other. Or we could just nationalize it. We know that everyone wants it, we know that it’s a very basic feature, we understand how it can be made, we can optimize it, it makes sense from my point of view to nationalize these kinds of things.

Jacob Arluck added:

“…And also having a much smaller surface of diversity, you don’t really want people implementing the same thing over and over again.

Tickets, which is implemented in OCaml, could have big implications for upcoming projects that could be looking to build on top of Tezos, such as Coase. This is because NFTs could be a good use-case for Tickets. With Tickets, you can only have one of them as they are unforgeable, which make them compatible with NFTS. The key elements are that the amount of contract calls,  expense and network congestion will be reduced. It could also make the design of such NFT projects much simpler. One interesting fact about Tickets is that they are cuttable with the Split handle. Gabriel Alfour explained to XTZ.news that:

“It depends on what you want to represent. If you take a permission, it shouldn’t need much to split it in half, except if you want your permission to be multipliable. Let’s say the quantity associated with your permission is 0, you just want to check if someone has the permission, you can split it and both permissions will have a quantity of 0. That lets you have your permission and transfer it to other people. So that would be one way to use it and that’s for a permission that you want to be able to transfer to other people and keep for yourself.

Then you have a permission, that will have a quantity of 1, a single permission that you cannot transfer, a form of rights that is given to you and no one else, so that if you split it you will see that the quantity will be lower than 1. The contract in the end that will check it will see a lower quantity than 1 and will see a lower entity than 1 and will refuse it, so that will be like for a personal right.

If you are interested in a quantity higher than 1, what it represents is basically tokens, fungible tokens. So, you can say that you have 10 tokens, and the contract could consume, like 5 of those tokens and you would still get 5 in the end. So the idea with tickets is that you can represent both permissions and tokens, depending on the policy you implement in the contract.”

When asked if you can assign tickets to an NFT card that represents a character in a game and then potentially split that card into fractions of cards, Gabriel Alfour answered:

“You could actually have the remedy of markets that would be completely ok. But here the more idiomatic thing would be to have a single card and the quantity assigned would be 1, but if later the contract emits more cards then you can just aggregate them and have a higher quantity. It makes more sense to see it that way. But yes, theoretically it will be possible to split your card in like quarters and then sell them in derivative markets and them buy them back and assemble them and then use them in the game if you wish”.

The Tezos tickets variation has even been tweaked since the original conception which involved a form of ‘punching’ a ticket to take ownership. When the original concept was created:

“you had to consume your ticket explicitly when you received it, now it’s done automatically through linear types, like Move” (Facebook). So, you don’t need to consume your tickets whenever you get it. Whenever you get it, it is implicitly assumed that the contract that sent the ticket to you wanted to get rid of it.”

This takes away unnecessary inefficiencies and enables a more user-friendly and streamlined experience for the user. It has also aided the developer experience.

“(Punching) ‘makes the developer experience a bit heavier because you have to write ‘Punch’ basically. However, what it would have let you do is for instance would be to send a ticket to two competing people and to have the first use it and punch it. What we have at the minute with Linear types, there is only one handle to a given ticket at a time, whereas before you could have had multiple handles and only the first one using it could have claimed it. Forbidding this prevents in theory some kind of architectures, but in practice we haven’t found this to be a problem. The constraint of linearity of having one handle to a ticket at a time is the most natural model”.

Tickets are part of the same amendment as Sapling (which seeks to enable private smart contracts on Tezos).  When asked if Tickets and Sapling could somehow be combined to create private Tickets Gabriel Alfour stated:

“That seems quite hard to intermesh, basically because Tickets rely on public assumptions. To have this linearity constraint, you need to know all the places where Tickets can be used, so that you can enforce this statically. So, in theory it might be possible to have this mesh with things like this, but this work has not been done so far”.

When it comes to how tickets feature against token standards such as the FA variations, Jacob Arluck part of TQ, developers of the FA 1.2 and FA 2  Tezos token standards went on to mention:

“you would probably just want to have the ability to wrap FA 1.2 or FA 2 tokens as tickets, you know the meme where it is ‘What somebody sees?’ vs ‘What somebody else sees’, it’s like what the external contract sees: Tickets, what the user sees is FA 1.2 and FA  Tokens FA 2.0.

You have a standard representation of permissions to other contracts and they can even see these as assets, like a pure asset contract, I think in some contexts with really granular on-chain permissions, particularly things like NFTs, DAOs and algorithmic stablecoins, it seems like there is a lot of fit for using Tickets as native assets. But for things like digital securities or other types of permissioned assets, for example if you want to have some kind of escape hatch in a marketplace, even just for a time, those are situations where this is a little awkward right now, so anything involving the freezing of assets my understanding is that is not as good as a fit. 

So, what difference will Tickets represent for the average Tezos blockchain user? Gabriel Alfour answered:

“Basically, it depends on which layer you are thinking of the UX, ideally for the user there should be no difference. The main different would be that let’s say you have a smart wallet, right, so you have your contract which holds your keys which holds your tokens. So, if you have a smart wallet right now, let’s say in Ethereum, you won’t have tickets within your storage, it’s mostly the address of your contract that will be linked to a bunch of ERC-20, ERC-721 and things like this.

So, it means that the smart wallet needs to know everything that belongs to you to check all the smart contracts that currently exist, so that is possible, but in practice some wallets will ask you to tell them on which on which contracts you have tokens and stuff like that. With Tickets you don’t have this problem because everything is in your storage. You completely own those Tickets; it’s not just represented in a separate ledger. For those smart wallets, it will be much easier for them to list your tokens as they will literally just need to get your contract storage. So that will be one way for the end-user to notice a difference.

But I believe the main difference will come from the developer experience. Right now, let’s say you want to do a Uniswap call. So, to do a transfer to Uniswap of your tokens, Uniswap will need to check the balances that it has in the difference tokens with the contract and things like this. Basically, it creates a lot of interactions between smart contracts, which is a thing that you want to avoid. Most failures of security or reentrancy attacks come from this interaction between smart contracts, with here with Tickets the thing will be trivial, you basically send a ticket of your tokens to the Uniswap and it sends you back another ticket and that’s exactly how you conceptualize this transaction in your mind. It’s just that right now because of basic concurrency models in most blockchains we have to implement this in very convoluted ways with a lot of round trips in smart contracts and things like this, this is really bad.

Right now, with Tickets you can have this straightforward thing, where you just send a token and you get a token back and that’s it. This is why I say ideally there will be no difference in user-experience, but in the developer experience and the safety properties you can get you will see a massive difference. It will be much easier to have something as safe or safer than what we have right now.

The big problem with safety in blockchains is not checking that your contract adds 1 and 1… the big problem is I am calling a bunch of contracts and I want to be sure that everything is done in the right order, that everyone has control at the right time, that the storage of the contracts are updated at the right time and things like this, that’s the biggest problem and that’s mostly about what I care about when we implemented Tickets is was a way to manage this concurrency in a safer way. “

The implementation of tickets is expected to be formally verified, Gabriel Alfour clarified:

“There are efforts from Guillaume Claret to automatically extract Coq code from the OCaml code and then it would write proves in the Coq code that is generated from the OCaml one. So that would enable you to automatically generate proofs of the code. So far it works well and there are a lot of refactoring’s of the protocol to make this possible.”

Ethereum in recent history has faced rising transaction fees and network slow down due to the rise of decentralized finance protocols and AMMS (Automated Market Makers) such as Uniswap. The idea of Tickets could also crucially make decentralized finance on Tezos more efficient. This is because the token contract would not even need to be called through the use of Tickets.

One very exciting area where Tickets could be used is within DAO and decentralized finance projects. Jacob Arluck talked about Tickets in relation to the Compound project:

“Compound governance would be a good example. So, in Compound you hold Comp and you can delegate to other Comp holders or whatever. They actually have a pretty straightforward approach to this in Compound, but what we could do is much more fine-grain. You could have a Ticket that represents your voting rights, you can send it to somebody else and they could vote on your behalf and you can withdraw that right. 

There are a few different people experimenting with Tickets, we are working on a tutorial series to understand better how to use it for assets and wallet integration we’ll definitely implement the DAO framework (BaseDAO) we’re building with Tickets as well. 

There may also be options to withdraw such rights through wrapper contracts. On wrapper contract functionality with Tickets Gabriel Alfour added:

“Usually wrapper contracts are a bit of a pain, because they don’t mesh well, but with Tickets they should compose quite well. The main example to get this part is on Tezos right now and a lot of blockchains I’m sure, if you want to authenticate a call coming from a contract, the only way you have to do so is ‘Sender’, so it means if you had a wrapper contract: A calls the wrapper contract – W that calls B, then anytime that you will need to check that it comes from A, B won’t be able to check this as it will only see W, so B will need additional assumptions, it will need to know that it is wrapped by W  in some way to be able to interact with A.

However, with Tickets you don’t have this problem, you don’t need to make any assumptions about the environment in which B is because A can just emit a Ticket that W propagates to B and B just sees the ticket that has been emitted by A. This is why things compose much better with Tickets because you don’t need this direct call between two contracts. You can put any number of contracts between them and you will still have the tickets that is propagated. We expect a lot of things like smart wallets and tools built upon this quite easily”.

So, what makes the Tickets implementation so golden?

In short (and in addition), the introduction of Tickets can:

•  help to avoid potential issues that could arise from the Tezos message passing architecture when developers are creating smart contracts.
• be more resilient to concurrency issues.
• reduce the amount of contract calls, making Tezos development more efficient.
• enable self-custody of first class coins, rather than an assets represented by a smart contract ledger.
• help improve the developer experience.
• enable smart wallets with advanced permissions, where you just have to send the equivalent of a token to another contract that can represent your permissions.
• give better composability as contract signatures with permissions or UTXOs as there will be less programming in terms of interactions between parties looking to transact.
• help trust, in the sense that you don’t have to trust an auxiliary contracts codebase (even though many of these contracts are open-source – how many people who use them can actually authorize that they don’t do anything malicious).
• enable great flexibility as they can be compatible with both permissions and tokens.
• enable you to assign tickets to NFTs and it is theoretical that these tickets can be split and then even re-assembled. Meaning specific card characters can be assembled over time to use in a game.
• free up the blockchain for other use-cases to thrive other than just DeFi as less contract and call functions will be needed.
• make it easier for smart wallets to see exactly what assets you own as they form part of your storage instead of being represented in a separate ledger.
• make it easier for smart wallets (and potentially exchanges) to list tokens on Tezos as they will just have to literally get your contract storage.
• help to minimise the possibility of being on different shards when new transactions and interactions are created when it comes to sharding.
• be nationalized meaning an even less complicated developer experience and greater security as important features are made native to the core protocol.
• enable better composability in specific smart contracts, especially in things like wrapper contracts.

Disclaimer

Nature of Content: All content published on https://xtz.news, whether written, auditory, or visual, is for informational purposes only. Opinions expressed therein are solely those of the individual authors and do not reflect the views of XTZNews or its management.

Not Financial Advice: No content on this website constitutes investment, financial, legal, or tax advice. Users should not construe any such information as a recommendation to buy, sell, or hold any investment or security or to pursue any particular investment strategy.

Accuracy and Completeness: While XTZNews makes every effort to ensure the accuracy and reliability of information, we do not warrant or guarantee the timeliness, completeness, or accuracy of the information presented. The website may contain errors, omissions, or inaccuracies. We disclaim all warranties, both express and implied, regarding the information, including but not limited to, any warranty of merchantability or fitness for a particular purpose.

Endorsements: References to specific entities, products, services, processes, or other information does not constitute or imply endorsement, sponsorship, or recommendation by XTZNews. Blockchain technology is in a developmental phase, and the engagement with the technology and its associated entities carries inherent risks.

User’s Responsibility: Users are encouraged to conduct their own research and due diligence and to seek the advice of qualified professionals before making any investment or decisions related to content on this site. Engaging with blockchain technology, cryptocurrencies, and associated applications should be undertaken with caution, understanding the inherent risks involved.

Limitation of Liability: Under no circumstances will XTZNews or its affiliates, partners, officers, directors, employees, shareholders, agents, or licensors be liable for any direct, indirect, incidental, special, consequential, or punitive damages, including without limitation, loss of profits, data, use, goodwill, or other intangible losses, resulting from (i) your access to or use of or inability to access or use the site; (ii) any content obtained from the site; or (iii) unauthorized access, use, or alteration of your transmissions or content, whether based on warranty, contract, tort (including negligence), or any other legal theory, whether or not we have been informed of the possibility of such damage, and even if a remedy set forth herein is found to have failed its essential purpose.

Seek Independent Advice: Before undertaking any financial investments, potential investors are advised to seek guidance from independent financial, legal, and tax professionals.