As I explained in my first video, Anoma brings incredible innovations regarding the exchange of value, in particular thanks to its system ofintentions and validity predicates which allows to personalize the queries. But, this is not the only new element brought: Anoma also has a state machine (state-machine) capable of effectively managing transactions involving more than two people.
Unlike most current smart contract platforms, which struggle with large numbers of participants, Anoma has no problem with transactions where 10, 50, 100 people are participating. Why such a difference ? In fact, it’s basically because these kinds of exchanges work much better with intentions and validity predicates. Or to be honest, it’s even quite the opposite: it’s extremely difficult to achieve this without the system of intentions and predicates.
You already know how this system works if you looked the first video, so I will not describe it again. Instead, we will focus on the new possibilities offered by Anoma and its system of intentions/validity predicates, such as in the case of multiparty transactions.
The future of decentralized commerce, at your place tomorrow
As explained in the introduction, the numbers of people involved in multiparty transactions can be enormous. We will certainly be able to see from time to time chains of 100 intentions combined with each other to form a single valid transaction. But that’s not very practical as an example in an article like this, so to illustrate things, we’ll settle for a transaction involving 3 people.
Let’s say this hypothetical multi-party transaction includes the following participants:
- Alice, who has twenty tickets for a concert and wants to get rid of those she will not use in exchange forETH, BTC Where USDC,
- Bob, who wants to buy 2 tickets for a maximum of 1.5 ETH,
- Charlie, who wants to buy 3 to 5 tickets for a maximum of 0.2 BTC.
This transaction will be added to a block if all the validity predicates are satisfied. In this case, it concerns the validity predicates of Alice, Bob and Charlie, but not only: the validity predicates of the assets used must also be satisfied. For example, if Charlie is paying in USDC and the USDC validity predicate dictates that he is blacklisted and prohibited from moving his assets, then the transaction cannot take place with him. In principle, because of this, no solver node will propose a solution of which Charlie is a part. On the other hand, if a solver makes an error and includes it in the transaction, this transaction will simply be rejected.
Let’s imagine rather than Charlie pay with an asset who has no problem of centralization in this kind, and that nothing opposes his participation. As long as all the validity predicates of all the addresses whose state will be changed do not oppose this transaction, then the state changes will be implemented, and the transaction will be committed.
And speaking of validity predicates, this is what Alice’s might look like, who wants to keep at least 3 tickets for herself and her friends, no matter how much she manages to sell.
use anoma_vm_env::*;
[[validity_predicate]
fn validate_tx(
tx_data: Vec,
addr: Address,
keys_changed: HashSet,
verifiers: HashSet,
) -> {
post_state[“NFT_CONCERT/Alice/balance"] >= 3
}
With this validity predicate, any transaction that would bring the total tickets in Alice’s wallet to less than 3 would be rendered invalid. And this, no matter what she might write in her intention.
So she doesn’t really need to specify a maximum amount in the intent, and she can do confidence in the system to give her what she needs. All that is needed at the intention level is to express what asset is offered for sale, what price is desired, and what assets are accepted as payment. Then she won’t have anything to do but wait and enjoy the concert. Assuming she set a reasonable price. If no one wants to buy because the price is too high, the intention system is not going to solve the problem.
And what’s also interesting is that if Alice changes her mind and doesn’t want to go to the concert anymore, she can just modify its validity predicate or delete it so that the line concerning the minimum number of tickets to keep no longer appears or is ≥ 0.
All this therefore makes it possible to validate transactions involving several people, but what about the multiparty negotiation that can sometimes precede it?
The preliminary stage: multi-party negotiation
The scenario here is quite simple: imagine a group of friends who are going on vacation and want to rent an apartment or a house somewhere at the beach. In this case, we have a group that collectively wishes to negotiate with a single entity, the lessor. There is maybe 10 people in history, but only two “groups”: the tenants and the owner.
The group of friends will first have to agree on the characteristics of the rental sought, the price, the distribution of costs, etc. Once that’s done, it’s very simple: they will all have to publish the same intention. To avoid being stuck with strangers, they will certainly also have to specify the list of expected participants, in addition to all the other characteristics of the transaction. Then, we go through the normal process, the validity predicates are checked, the amounts present on the address, and so on.
Instant micro-DAOs: decentralized collective commitments
You undoubtedly know what a CAD, and basically, we can say that those who are members undertake to work to accomplish the missions of the said DAO, in a large number of cases. But DAOs are not one-size-fits-all multiparty solutions, especially when network users need a more ephemeral way to form an alliance to achieve some goal. How to do without using a DAO?
For now, on traditional networks, there is not really an answer to this question, but you are in luck: Anoma has a solution.
Let’s imagine, to explain all this, that a group of users wishes to unite as consumers to encourage large companies to manufacture products in an eco-responsible way. These people do not want to set up an association. Indeed, it is a time-consuming process and does not guarantee results: they prefer to hit the manufacturers’ wallets directly.
On Anoma, they can use collective commitments : it is simply a matter of publishing an intention according to which they all declare that they want the same thing, that is to say the purchase of a product which respects certain pollution standards, or for example the purchase of a product for which the producer has proven that he has purchased X carbon credit units.
By using a reliable oracle that provides data on the production of the products concerned, it is possible to write an intention that blocks any transaction related to polluting products.
With this system, producers will be able to see how many customers are demanding compliance with these standards, and will therefore be able to calculate the impact of these requirements on their profits. If enough people sign up, there will be a natural incentive for producers to meet their requirements in order to be able to sell their products.
The only potential drawback of this whole system is that in the case of products existing in the real world and not on the blockchain, one must have a reliable oracle, of course… If there is no reliable oracle is more difficult to implement. That said, a “home-made” solution where participants simply communicate on a forum and decide internally which products correspond to their criteria could very well work. In fact, in practice, it wouldn’t be that different from the “adblock lists” we have today: activist users could get together and compile a list of approved products into a list, then publish that list to an address well defined, on the internet or on a channel like Arweave and Ceramic. Then end users could simply subscribe to those lists, embed them in an intent or their validity predicate, and that’s it. If the wallets natively integrate this listings functionality, or allow the use of plugins that will do so, end users could still realize their convictions very easily.
Collective commitments therefore allow consumers to unite in a new way without having to worry about intermediaries. They can directly influence the manufacturers of their favorite products, in a completely decentralized way, without having to really organize themselves formally and create an association or any group. The intentions, which are only bits of code, can be spread by email, between friends, between strangers on platforms like Twitter, Telegram, or even 4chan… And will still lead to concrete results.
Relational intentions: complex but very useful intentions
This type of intentions was designed to meet the most complex requests that network users may have. That is to say, they allow condition the validity of an intention to that of another intent, so that a transaction is only validated if certain very specific intents are all part of it simultaneously.
The most emblematic case that one can imagine is that of someone who needs to travel, to find a hotel there, and to go and do something once there, like going to a concert or a play. To satisfy this person, each of the operations must respect certain criteria (date, number of stars of the hotel, travel time by train, etc.), and all three must not exceed a certain total price.
This is where relational intentions come in handy. To achieve the objectives set, it is possible to publish a special intention which has its own validity predicate, which refers to 3 “sub-intentions”, each of these sub-intentions relating to one of the three transactions to be carried out. There is a sub-intent for the train, a sub-intent for the hotel, a sub-intent for the show/theater ticket, and a validity predicate dictating that all three must be satisfied simultaneously for a transaction to can be validated. In this way, even the most demanding users can be satisfied… As long as there are indeed sellers ready to give them the products requested under the requested conditions, of course.
Thanks to the intentions and predicates of validity, Anoma is able to satisfy all the needs of users, including the most eccentric. And what’s more, there is no real limit to the number of participants if a transaction involves several people, which really makes it a system suitable for the general public.
