Presentation of XBI by Maciej Baj at a Substrate Seminar, hosted by Parity Technology

Welcome to another in-depth article on XBI. This one is a transcript from Maciej Baj's (t3rn's founder and CTO) presentation at a Substrate Seminar, on August 16th, 2022, hosted by Parity Technology. Here is a link to watch the presentation on Youtube.

The goal of this presentation is to educate builders and programmers in the Polkadot ecosystem about XBI (Cross-chain Binary Interface), an XCM-based binary interface for smart contracts, developed by t3rn and funded with a grant by the Web3 Foundation.

Enjoy this presentation, and if you have any questions or want more info, join our global community of developers building with t3rn in our Discord dev channel.

‍

XBI: an XCM-based binary interface for smart contracts

You can think of XBI as a plug-in to XCM, an extension.

We would like to see more standards coming to XCM in general, and that's why we decided to work on standardizing the transact operation to XCM by proposing XBI.

‍

What is t3rn?

t3rn is about cross-chain execution in general. We want to engineer cross-chain execution by allowing developers to build smart contracts with the languages that a smart contract developer likes, such as Solidity or Ink!. What we use to process those smart contracts on the t3rn side, we call 3VM.

3VM doesn't discriminate whether the smart contract and bytecode are in WASM or EVM, and it introduces several new concepts. The virtual machine extrapolates what we call side effects.

The side effects are the orders of operations that need to happen on the remote chain. To allow this, we provide a heterogeneous platform for the smart contracts to work on the same mechanics regardless of whether the transfer will happen on the same ledger or whether the transfer is, for example, targeted to a remote consensus like Ethereum or a remote parachain like Moonbeam – it should still be the same smart contract.

The one thing that we focus on in t3rn specifically is that we put extra emphasis on all of the traffic that goes through t3rn to be completely trust-free.

For all of the messages that are incoming back to t3rn, we use light clients for verification, and for each remote consensus mechanism and all of the traffic that comes from the parachains, we rely on XCM.

There is also the additional coverage for designing these smart contracts with t3rn, where we take on the opportunity of designing the economic mechanics from scratch.

Additionally, we think it would be an interesting experiment for all developers that build smart contacts with t3rn to provide a feedback loop of rewards that their smart contracts generate. So the traffic and the gas fees that their smart contracts generate will provide feedback to the original output. The more traffic your smart contract generates, the more revenue it gets to the original outlets.

An essential aspect of all the cross-chain execution in t3rn is that it's safe. So you still have the same characteristics you would expect from the smart contract that runs on a single chain, like Ethereum.

In case you have multiple calls, multiple transfers, and the execution breaks – e.g. if it runs out of gas throughout the execution time on Ethereum by default, Solidity will roll back all of the previous operations.

We try to map the same pattern to t3rn while functioning in the cross-chain environment; this is what the t3rn protocol does.

We provide the complete bootstrap of the ecosystem for the current protocol and the setup of the t3rn protocol. We have different parties working together: Attesters, Executors, and Collators provide the setup for the trustless verification of all of the incoming proofs that would verify whether the execution was correct or not.

You can see the UI we're working on , which gives you more insights into how the protocol and the mechanics work in detail.

You can compose your execution with multiple steps, and all of those steps will either go through or get reverted. This is a simple and easy demonstration of the t3rn protocol.

‍

How would you compare what t3rn is doing with other smart contract platforms in the Polkadot ecosystem, and what makes t3rn special?

We primarily focus on the fail-safe aspect of the whole execution.

In the contract register, we bootstrap what we envision becomes the place where interoperable contracts get created. We provide the virtual machine to execute on multiple different parachains or consensus systems.

You can think about a call that would happen, for example, on Moonbeam, BNB Chain, Astar or Ethereum. With t3rn, you will use the same standard methods such as transfer swaps, adding liquidity calls, etc. And it will work exactly as it would have worked on a single ledger.

We would like to see an environment where you can build and engineer the strategy and the smart contract that would execute in the same manner that would result in one chain on multiple chains.

t3rn will provide a platform that can execute the smart contracts that developers create on multiple different consensus systems and offer trustless proofs that all of the execution actually happened in case something goes wrong.

For example, if you create a smart contract and gas runs out on the call to Astar, but you already made the call to Moonbeam, it leaves you in a pretty funky situation.

There could be a case where you already made some irreversible action on Moonbeam, and the whole flow didn't fully succeed. In this case, what the developer envisioned in the strategy and was written in the smart contract couldn't succeed.

For example, you only hit the two hops to two different consensus or blockchains, and the third one didn't happen. What do you do with this dirty state?

t3rn protocol becomes handy because, in this whole phase of mechanisms, we take care of cleaning up all of the side effects that happen. To fix this, we introduced a new concept, an escrow mechanism that waits for the final commit message and the final commit confirmation after all of the events have already happened and been confirmed in a trustless way to all of the different chains a, b, c, and d.

‍

‍

Once all of the proofs are ready and delivered, it's time for the final commit dispatch message that frees up and unlocks all of the side effects that should have happened on the selected chains.

This is why t3rn is different from other VMs. We focus primarily on the popular concepts when designing smart contracts on the single ledger and map the same concept, which is difficult to achieve in a safe scenario, in the interoperability realm.

‍

Why isn't XCM enough?

We are focusing on XBI to have a standard way of submitting the executions and the execution orders on all parachains connected within Polkadot.

XCM isn't enough for t3n's use case, where we try to have particular standard operations.

The smart contracts we see developed on t3rn will call to EVM, call to WASM, transact different assets, swap, add liquidity, etc., and the consistent way of getting back the confirmations whether some operations were successful or not.

We will be iterating on the callback systems and how they would work with XCM. We will also provide a consistent way for developers building with t3rn to have strict control over the costs of both delivery and execution.

Developers will be able to set a standard way of expressing the max execution fee they can afford; ideally, we don't want them to take care of all the specific details.

We want to handle as many automatic conversions between the delivery fees and the execution fees behind the scenes. XBI is translating all of the fees and aggregating them in the most useful manner.

With XCM we don't see it following this direction, and this is probably very good because XCM is something that should work for all of the parachains. Not all parachains have all of the custom features they would like to use.

We see XCM being super efficient and valuable in bringing on primitive security and the trustless dispatch and execution of delivering messages.

XBI standards will bring more specific use cases on evolving XCM to adapt into something more customized to the use cases t3rn is suggesting.

The way XCM is engineered is very generic, so all of the primitives that XCM will be using are prepared to serve many different consensus systems and chains simultaneously.

‍

XBI format as the new standard for XCM

XBI is just the standard of messages that would go through the XCM transact, so all of the security we're deriving from XCM with the additional payload and format that every other parachain that adapts to XBI standard could rely on and use.

We envision it being used and efficient to propose a new set of instructions relatively quickly.

For example, Phala. If they would like to see some extra operations being useful for their specific private computing messaging, they could easily extend the XBI format. Then all of the other parachains that would like to use XCM for communicating with projects like Phala rely on those specific operations and have a standard for the particular operations.

The XBI standard could be easily added to that, and at the same time, you would still have the same metadata structure. The metadata structure is essential for us to have the standard way of dispatching the callbacks and controlling the delivery and execution costs.

You can think of XBI as a high-level API where each parachain exposes its customized functionalities and makes them accessible to other parachains while relying on the security of XCM, using the XBI standard to call one another.

‍

The XBI format PSP

XBI is funded by the Web3 Foundation, which we are thrilled to work with. It brings XBI closer to adoption.

A standard is only as useful as its users adopting it.

The first grant proposal that we got is going to end up as a PSP (Polkadot Standard Proposal), which is something that we are now actively working on with a couple of selected partners to make this first draft of XBI useful for all of those partners and to make sure that the first set of operations and the metadata that will be included into XBI is something that will be adopted and used.

‍

The XBI example

Let's dive a little deeper into what a particular XBI operation looks like.

‍

‍

‍

We have two main components, essentially. The first one could vary. In this example, we have an instruction of XBI.

On the top, we have a call to our EVM. It will consist of several values like account IDs, source targets, etc. All of these parameters that the call to the actual EVM pallet would use.

The one thing that we would like to follow with XBI is not to be as generic as XCM.

For example, for accounts, you have two types that are used. There is an account that is 20 bytes long, which is used for EVM-based accounts, and accounts 32 bytes long which are all of the standard accounts on Polkadot.

For these two different types of accounts, we have several different values, and we select one of them to be set as the standard for EVM, which also helps us in the coding/encoding between those operations.

This would be the first part of XBI, the instruction.

The second part of XBI, which is always going to be there, is the metadata. The specific periods of the metadata that are going to be there. For now, it's going to be a custom ID that lets you identify your XBI queries by a custom identifier that you set.

For all of the XBI messages what we do with pallets that are there to dispatch and manage the check-in and check-out cues for XBI messages, what really would be beneficial from the perspective of protocol selector is a consistent way of being sure that there is going to be a timeout on the sending out delivering and executing a particular XBI operation. And if this timeout is going to exceed, then you're going to receive a callback with the wrongful execution of this particular reason and why something failed.

Max execution cost, max notification cost, additional fee, and known origin, you can submit it or not, and there's also an interesting idea to have the additional option appear which is going to be an optional asset id, because maybe you don't by default want to pay and express all of your maximal execution costs in the source native asset, but perhaps you can specify the additional asset id which the processors are going to be calculated and subtracted from these accounts.

XBI orders now

• Unknown
• CallNative
• CallEVM
• CallWasm
• CallCustom
• Transfer
• TransferORML
• TransferAssets
• Swap
• AddLiquidity
• Result
• Notification+

‍

There is also the unknown operation, which is a nice trick. We use a custom codec because by introducing the unknown operation all of the parachains that would receive the operations, for example, what was added in the next iterations and expressions of the expiry rollout or going back to the nature of how we see XBI standard going, is that we don't assume that all of the parachains would have all of the support for all of these particular XBI orders.

Let's go back to the example of Phala. If Phala introduced some specific XBI order for those who can't receive this particular Phala order, this XBI operation should link is unknown, but all of the parachains that know how to process the specific XBI operation from Phala will be translated as the proper and the correct XBI message.

‍

The lifecycle of messages

The lifecycle is something that is being expressed by the XBI metadata and the management over the lifecycle is divided by the check-in messages and the check-out messages.

The check-in message is the XBI order instruction, and then check-out is either the notification or the results.

All of the traffic goes via XCM transact so the XBI messages are going from parachain to parachain until they reach the destination and the destination decides whether it is the time to check out the operations because maybe it is executed fully successfully or maybe the timeout got exceeded and now it needs to send the notification and the result back about the wrongful or the failed execution.

Here is an illustration of the pallet that we currently are working on that would process all of the check-in and check-out cues.

One thing to add is that we implement all of this management over the queues as much as possible in the off-chain worker so the management and handling of all the timeout goals are implemented in the option worker and all of the XBI cues.

‍

XBI integrates via a set of pallets

We imagine the integration of XBI as a set of different pallets depending on how lightweight each parachain would like to go with implementing a particular XBI standard, because it could be just the dispatch of a method without processing all of these queues as we saw previously. Or it could be a collective portal handling all of the lifecycle with those additional storage engines and this additional worker that would manage all of the check-in and check-out queues.

XBI and the configuration of the XBI portal pallet work based on the trade to this pallet working as the dependency injection where you simply specify whether your parachain supports WASM or not, whether it supports EVM or not, and whether it has RML pallet or not.

A sort of plug-in-like approach where we assume that most of the parachains won't have all of the XBI orders enabled by default but could say, for example, we don't support this particular pallet and these particular XBI operations. Still, one of them may be an excellent way to configure the extra specific messages.

‍

‍

The plan ahead

The plan is to work alongside a handful of partners with a couple of producing teams on the first draft of XBI, resulting in our first PSP proposal. By then, XBI will be useful for other projects and be able to experiment with it.

Then we will open source it to the public and open the proposal for suggestions so the proper management of which XBI instructions become part of the standards or not.

We are currently live on the Rococo testnet, and soon we would like to install the XBI pallets and start live testing with other parachains.

Feel free to reach out if you want more info or to add any feedback to XBI in our dev channel on Discord.

👉 Subscribe to our newsletter: Join 15,000 subscribers for exclusive monthly updates and insights, directly from Maciej Baj, founder & CTO of t3rn. - no spam, unsubscribe anytime.