XBI: A new standard for fail-safe and trustless cross-chain execution
This blog post is based on Maciej Baj's presentation of XBI at Polkadot Decoded 2022 https://www.youtube.com/watch?v=92w8rVXB5q8
XBI is the standard we are working on that primarily focuses on communicating between different virtual machines, so if we have an EVM virtual machine installed on one parachain we would like to enable communication with all of the other pallets on remote parachains and also to translate between the environments of WASM virtual machine and EVM virtual machine that also lets us specify all of the metadata that is necessary for XCM operations to function in a good way but also goes a bit deeper into the callback system. Hence, we have a consistent standard way of not only submitting the execution to the remote chains but also receiving the notifications of delivery and results.
t3rn: cross-chain, fail-proof, composable, & developer rewards
For those who haven't heard about t3rn, we like to be seen as the hosting platform for smart contracts and don't discriminate between solidity and !ink developers. We provide the SDK that allows for building cross-chain smart contracts in both of those languages.
We would like developers to work on the primitives that also offer fail-safe execution. When you bundle together multiple calls that would happen throughout the execution of the smart contracts, you don't want them to end up in a dirty state. For example, if the fourth call out of four runs out of gas, you don't want to see your smart contract in a dirty state, where some side effects have been left on the blockchain. So what we do in t3rn is elevate the concept that smart contract developers are familiar with from the single ledgers now to the cross-chain realm.
To additionally incentivize sustainable growth of smart contract ecosystems, we take advantage of being able to design entirely new ecosystem rules. Hence, we want smart contract developers that build with t3rn to have a sustainable way of remuneration. The way it works. We feed back the loop of all the gas fees that the smart contracts generate back to the original authors, and then, on top of it, we are designing the token economics that will incentivize the healthy growth of the smart contract ecosystem. We will also have a DAO-like community that will say which smart contracts are critical for the community to focus on building. The community can express which smart contracts should be additionally incentivized from inflation.
t3rn interface
In June, we launched to rococo, and we're also working on a slick user interface that allows users to build cross-chain transactions in a simple drag and drop-like fashion where all of the targets that are already connected to the rococo parachains will be available, and you can submit the transaction to the t3rn protocol and in a trustless way receive all of the incoming messages from the remote parachain.
Composing trustless cross-chain execution
Security is a critical concern for T3rn. All of the incoming messages and their inclusion are being verified by our publicly verifiable light clients. For example, incoming messages (assuming t3rn is installed on Polkadot) and incoming messages from other relay chains like Kusama we're able to verify using light clients that are in charge of reading the grant for finality proofs. Upon verifying inclusion, we then proceed with decoding an event. We compare the values from the incoming event with the values that the user source developers have submitted and it goes on and on.
The importance of trust-free bridging
This part of t3rn is similar to a multiple adaptive bridging protocol that is adaptive to multiple consensuses. Most of the current bridging solutions work on the basis of multiple parties agreeing and attesting to whether the incoming transaction from the remote blockchain is correct or not. Those multi-signature parties can be either open or closed, meaning that either you can essentially have enough stake to participate in the consensus of a particular bridge protocol and be one of the valid validators that would be in control of signing on the correct attestations, or probably the easiest setup of a bridge protocol is where you have closed federated nominated parties that aren't really meant to change.
The problem with bridges
We saw a couple of problems in the past few years where some of the bridge solutions got exploited. Here are the three main reasons for the exploits:
- When there is a low factor of collusion, it's possible to take control over the validators attesting to the validity of incoming transactions throughout the bridge. We saw it happen with the Ronin hack, where an attacker was able to take over the control of a node that was hosting four validators. Only five of the validators were enough to take over the control over the bridge. Then the attacker was able to collude one additional party and took control over the bridge withdrawing more than 600 million.
- Another part of the exploits is connected to just simply bug implementations.
- Many exploits are also connected with the exploit of the THORChain bridge. They were bridging to Ethereum, and then the attacker was able to wrap the original Ethereum smart contract in its own smart contract, which caused the override loop of the vault transfer to then withdraw the funds. The THORChain<>Bifrost bridge exploit was for $5M.
You can protect yourself from the bug implementations and hackers exploiting your open source by making it closed source, but it breaks the properties you would expect from blockchain when you can, as a user, publicly verify that all of the traffic that goes through the bridge is intact.
XCM is trustless
XCM is on a different level of security. All XCM messages are governed and protected by the GRANDPA finality consensus. Most of the total value of the Polkadot network is currently staked. You have more than twenty thousand nominators that can vote on more than two thousand active validators, so the security and the degree of decentralization is very much in place.
Why XCM isn’t enough. XBI format as a standard for XCM transactions
XBI fits into XCM by adding an additional standard to XCM transactions. XBI sits inside the transaction operation mechanism, and XCM is designed to connect all parachains. XCM comes with its own virtual machine, but it's really very generic and it should stay like this in order to connect all of the parachains.
Where XBI shows to be useful is adding additional standards over the transactions. Originally the XCM transactions allow you to pass any code dispatch without having the full awareness of whether the destination chain has installed the code that you are dispatching via a transaction.
Also what we would like to see is a consistent way of receiving the callbacks (the notification) of delivery and execution, either correct or wrong. This is also what XBI ads to XCM transactions. It allows developers and users of XBI to specify the metadata that shows all of the necessary timeouts that you receive the notifications but also goes deeper into selecting all of the specific XBI orders. We focus primarily on making sure that the orders of calls on a wasm contract pallet and EVM pallet can talk to each other. Once you create the call from EVM it can be dispatched and targeted to another environment on wasm and the other way around. We also construct all of the cues and messaging systems that pass the messages back and forth.
The XBI format PSP
XBI is flexible, and we use a custom encoding. The custom encoder doesn't enforce all parachains to be aware of all possible XBI orders. On the other hand, if XCM is rolling out a new version, all of the parachains should upgrade to the latest versions. With XBI there are no such requirements. For example, two parachains can agree to use some specific.
custom functionality that would be only available for those two parachains to communicate, and the other parachains don't necessarily need to be aware if they receive such XBI order, they can't understand it and they will automatically decode it as an unknown order.
It's important to mention that the XBI format is funded by the web3 foundation and will conclude with a PSP Polkadot standard proposal that will further the adoption and integration by other parachains to switch to XBI or perhaps use it next to standard XCM messages.
The lifecycle of messages
Lifecycle overviews that we pack all of the XBI messages into a XCM:transact and packs not only the calls but also all of the notifications and acknowledgments of delivery and execution and transmits them back to the source parachain that created the orders.
We developed a palette that controls all of the queues. We tried to offload as much as possible from the runtime, so the management over the queues has been done by the off-chain workers
that control all the timeout mechanisms, the check-in queues, the checkout queues for notifications, and the results.If the destination parachain is the target parachain, then it dispatches this result on one of the hooked-on pallets that have been defined by the XBI portal.
XBI integrates via a set of pallets
The XBI portal is able to be configured with multiple different traits expressing which
specific XBI orders will be handled by the parachain. It’s in the design of XBI forward messaging that not all of the parachains will have all of the traits configured. For example, we have WASM on one parachain, but not EVM, a ORML pallet for multi-asset transactions,a pallet asset for multi-asset transactions, and potentially more and more XBI orders
that we would hope to see being proposed by other parachain teams.
When developers use XBI
Where t3rn fits into XBI. We'll use XBI to communicate with all parachains and give us a consistent standard. We're working on an SDK for developers to build cross-chain smart contracts.
Here you can see the types have been taken from XBI, and it's possible to just create the account ids that will be compatible with EVM. So 20 bytes with other pallets of 32 bytes can all be mixed up in the flow, that defines a smart contract that is cross-chain.
Essentially, we have one smart contract that defines all of the flow that should happen on the remote target while guaranteeing that all of the execution will be fail-safe by t3rn.
We additionally expose the function that lets you specify the XBI metadata. This way, developers are more in control of how the timeouts would actually function, so they can specify when is the time out of delivery and when is the time of execution. We see it being useful for many use cases so we want to give the power to developers and simplify the good use cases for cross-chain applications in general, as well as give them control over the flow.
Soon we will be releasing the SDK and the user interface.
If you would like to hear more from us or discuss potentially extending the XBI standard because you see some messages missing, feel free to reach out!
You can follow the XBI progresses by tuning into our channels, on telegram and discord, or by observing the web3 foundation grant proposal, number 903
👉 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.
