An XCM-based high-level standard and interface (ABI) for smart contracts.
License: Apache License 2.0
An XCM-based high-level standard and interface (ABI) for smart contracts.
The XBI standard is undergoing a lot of iteration, the details can be found in ./docs.
Whilst XBI should be modular, so should extensions on XBI. Each extension can be roughly explained here, and any links to the grant proposals seen below:
Spike
AS A message requester
I WANT to specify a timeout that a message can take to execute
SO THAT i can have garuantees by xbi
A user must be able to provide a timeout in an XBI message. This is quite relevant when it comes to asynchronous backed channels since the time it was requested will most certainly be different from the time it was sent, or executed and so on.
However, there is no concept of time really, within a blockchain. We can take the time from aura but it adds a dependency on all parachains that use XBI to use aura or something else to give us time. A better notation is a block number. This is also tricky since we might send a message on #500 on source but then there must be a new timer for when we receive the message at block #12324 on dest.
It is probably reasonable to have something like two timers. Such as:
Really the two terminal operations of when a timeout should/could break are:
Really, these are the only terminal operations we should have in XBI.
Investigate risks that this approach might take and write the stories to improve time within XBI.
2d
2
Story
We need to add benchmarking to XBI portal, since everything is currently free.
This would take a reasonable amount of work since we are also benchmarking contract calls.
No response
None
Epic
AS a message sender
I WANT to be able to specify what is a successful message
SO THAT I can have fine-grained control of the result
A user should be able to specify to the receiver's instruction handler what a successful message means.
For example, a call to a smart contract is currently largely always a success if the contract was able to be called.
But what if the result is wrong? If a user is expecting a flipped to be true, and it returns false this is a failure, or is it?
Users should have this control because they have no guarantees the contract hasn't been modified since they inspected it.
This should be provided via the message metadata. Something like a validations field.
Additional information should be investigated via a spike to see if this is doable and the limitations/security considerations of such a feature.
Fill later
13
Task
These should be unified and the contracts abi should just be a bolt-on to Substrate ABI.
This can be achieved by a feature flag contracts.
Ensure any dependencies are updated, and ensure breaking changes are added to the commit so that any dependents will know about it.
contracts to expose SCABIcontracts feature flag1
Spike
Todo
No response
todo
None
Task
We should unify the requests and responses storage items in XbiPortal. This will make it easier for the queue to manage one set of items and provide clear checks.
This can be reduced to just Message since it contains everything needed for us to handle the queue.
None
Story
Timestamp progression is a little optimistic. We should use an enum and just call progress(Progression(block)).
This means we can easily see gaps in the timestamp process.
The progress function currently just takes a block number and assumes that the progression is moving from a -> b.
Update it to take an enum with a number instead, and simply update the field.
0.5
Story
We initially removed this, but we should check that XbiMetadata src == dest in the FrameSender and if so, use ExecuteXCM/InstructionHandler instead.
We need to inject ExecuteXcm into FrameSender, or we might just inject InstructionHandler. This would allow us to simply execute self without going over Xcm needlessly. This would allow the Circuit to send self-messages eventually without knowing about implementation details.
This should skip the receiver-post aspect of the message too.
Given an XBI message with metadata that is from self -> to self
When the message is to be sent
Then the message will not be sent
And the message will be handled by the src parachain instead
And src should be validated to ensure self is src
None
Task
When we built the barrier in Asset Registry, we forgot to create an integration test for it and install it.
Create some tests to prove the barrier works in real life using the integration-tests folder.
Ensure that only payable assets can be used. Create one with ROC unpayable and one with, make sure the fees are correct.
None
Story
TODO
No response
TODO
None
Task
Remove the id field from XbiResult since we have it in the metadata anyway.
Update the codec to remove the id. Everything should take the id from the metadata.
id is removed and tests pass
None
Story
For now, we have been emitting events with the results for debugging.
We should be storing the result to XbiResponses
Validation should be on the request of a message to ensure that the XbiId is uniquely stored, otherwise, return.
Introduce a trait for reading from & storing to XbiResponses or utilise one if it already exists within substrate frame_support. Inject this trait into the sender and store the result in handle_response.
Implement this for XbiPortal.
Also update the checks in process_queue to use the same trait implementation.
GIVEN a response
WHEN it is handled by the handler
THEN it is stored in the store
1
Story
We want to be able to reserve the funds for an asset rather than send them to some arbitrary account.
We currently have ways to "Reserve" an asset, but it does break the philosophy of XBI and isn't really anything to do with XBI.
There are traits InspectHold & MutateHold. These allow an asset to be treated much like ReservableCurrency, but I'm aware that they do not respect ExistentialDeposit. The other issue is that these traits are not actually implemented in assets and basically don't do anything.
One option, which is rather nuclear, is to introduce some DTO in our pallet-assets::Extra config to have the fields reserved and anything else. This does tightly couple any user of XBI to this implementation.
The other option we do in t3rn::AccountManager as a first-pass solution, is to basically just send the funds to a treasury and refund when we like via some ticketing system. This also cannot work for XBI since it couples parachains to use this very specific implementation.
We could in the meantime just send it to an account that the pallet owns, and pay it out, which we can do in the Queue PR. But this is a very feral implementation and is not for purpose.
Parity has introduced the true fix for it on this pr however this is very recent and we're still on an old version of substrate.
My personal proposition is to wait. And ensure we keep an eye on this PR and maybe retro fit it to a Newtype Trait, but still requires custom work on pallet-assets.
A
None
Bug
Since we switched to lcov, the coverage that is being sent is null
No response
none
None
Epic
We should complete the queue-backed channel. The purpose of this channel is to allow for the detached handling of messages, driven by a substrate on_initialize hook.
Most of this is in each channel part::queue_backed.
The portal pallet would need an extension to support both send(sync) and the async send.
For the most part, the queue is largely implemented, we just need hooks and we need to test them, we also need to add the costs of handling each queue part, and charging the user when we eventually handle the message.
We should also be refunding the user the difference in the message.
These tests should just call synchronous receive on the target.
GIVEN a message to asynchronously send
AND the message maximum cost is `5_000_000`
WHEN the user requests to send the message
THEN the user is charged the maximum fees for `exec & delivery` of `5_000_000`
AND the message is placed on the queue
WHEN the hook takes the message from the queue
THEN it should be sent over XCM
GIVEN a response to handle
AND the message maximum cost is `5_000_000`
AND the response cost was `4_999_999`
WHEN the queue handler takes the message
THEN the user is refunded `1`
AND the message result is written to the store
We should also be validating the signal of the queue, and ensuring that failed messages are popped to the back of the queue.
Gas should be returned from the init hook.
None
Story
A parachain should be able to update their own reverse lookup/master lookup.
This should be via an XBI call which would assume root on the parachains behalf to update the lookup.
No response
todo
None
Task
The current scheme is random. We should follow the same style as substrate, such is prefixed with s(substrate)p(primitives)-thething
Rename the manifest to follow xp-thing.
No response
Each primitive should be updated:
Consider also renaming sabi/scabi too.
Also channel parts to something like xs-thing (xbi service).
1
Story
AS A user
I WANT to be able to transfer
SO THAT I can send funds across the dotsama ecosystem
We want to be able to support multi-protocol transfer.
Currently there are a few ways to transfer over XCM
pallet-balances on destinationWe should support all three, based on the capabilities of each chain. Eventually calling native.
Introduce a new call in XBI portal, transfer which would determine which approach to take, if the parachain supports it for the asset.
TODO
None
Story
The pallet index is hard coded for 200 to XBI portal. We should figure out a way to resolve these indexes fairly efficiently.
No response
todo
None
Story
Users should not be able to generate an id, we should do it ourselves by a composite hash of a nonce field stored in the pallet and the XbiMetadata => hash(nonce, metadata)
Remove the ability to set the field by using codec::skip and ensure that it is received on the receiver or by some other means.
Also hide timesheet. Since this should not be set by the user.
Introduce a StorageValue item in the pallet named MessageNonce to increment_and_get on each request to send an xbi message.
Under no circumstances should it be implied that a user can set this message, it is not suffice to use an Option in the request. This should be handled smarter.
GIVEN a request to send a message
WHEN the reuqest is checked
THEN the `MessageNonce` should be incremented
AND the `id` should be added to the `XbiMetadata`
AND it should be the same when the receiver receives it
2
Story
This should be derived from max_execution_cost field in XBI
No response
None
Bug
We must have some magic configured in integration tests because everything from the BuyExecution call is just being burned at the target. This needs to be tied against the weight of the call and not just burn everything or at the very least allow it to be claimable.
Do test::user_is_refunded_most_of_fees_on_target_fail to see the events.
bug
None
Task
Sender & Receiver should be a single crate, limited by feature flags.
Feature flags should be for receiver and sender.
Both should be the default.
None
Task
Most of the converters in each channel crate can be a From implementation in the respective struct. Refactor these to use it and utilise DTOs.
No response
None
Story
AS A parachain
I WANT to configure how much I'm willing to pay to send the message back
SO THAT I am not sending messages for free
On each receiver-sender, we don't pay for execution at the destination to handle the response.
A parachain implementer should be able to configure this Response Cost and provide it into the channel so that it has ownership over the notification fee on its part.
Inject a Get into the Sender, and utilize this when the message is being responded to in buy_execution. The parachain that sent this should then pay the fee.
There is a small amount of complexity regarding the actual fee for the notification. When should it be charged?
Option #1 dumb option:
We can validate if the Dest response cost would overflow the aggregated cost and deny the execution
#2 Improvement:
We know about the cost and any details of the message beforehand via some registry of response costs and any other metadata
Utopian goal:
XBI gossips the costs via some inherent to all users who implement XBI
dsaasdas
None
Story
As a user
I want to be able to call t3rn protocol
So that I can access things outside of dotsama
We should support t3rn protocol via utilisation of UniversalLocation in XCM.
If we register /Ethereum then we can submit a side effect to t3rn to hit ethereum.
This would have interesting complexity regarding XBI timeouts and such. Needs spec
needs spec
None
There's some lockspec issue with clap on this, although it doesn't have the same issue locally. Should be a quick fix, as I've fixed it before, already.
https://github.com/t3rn/xbi/actions/runs/3863258425/jobs/6585335537
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.