Comments (5)
Might be worth doing fairly soon just as an example for explaining protocol usage.
from ibc.
Packet will contain:
- Denomination (string)
- Amount (unsigned integer)
Some nontrivial logic to prefix denominations and reason about alternative source paths.
from ibc.
edit: When reading, replace root-of-trust hash with connection identifier in the following text.
Thoughts on permissionless denomination tracking across chains, for chains A
and B
:
- Chain A
bank
module accepts new connections / channels from any module on another chain. - Denominations sent from chain
B
are prefixed with the hash of the root of trust and the name of the counterparty port ofB
, e.g.0x1234/bank
for thebank
module on chainB
with root-of-trust hash0x1234
. No supply limits are enforced, but thebank
module on chainA
tracks the amount of each denomination sent by chainB
and keeps it in a store location which can be queried / proven. - Coins sent by chain
A
to chainB
are prefixed in the same way when sent (0x4567/bank
if thebank
module is running on a hub with root-of-trust hash0x4567
). Outgoing supply is tracked in a store location which can be queried and proven. ChainB
is allowed to send back coins prefixed with0x4567/bank
only up to the amount which has been sent to it.
This design has the following properties:
- Permissionless, no need to whitelist connections, modules, or denominations.
- Symmetric (just swap
A
andB
- they both implement the same logic). - Allows inflationary tokens (e.g. for proof-of-stake) originating on one chain to be sent to the other.
- Prevents Byzantine-inflation of tokens originating on chain
A
, on chainA
, as a result of chainB
's Byzantine behaviour (though any users who sent tokens to chainB
are at risk). - User-unfriendly naming; will need to be managed via a UI or later nameservice module mapping prefixed denominations to common names ("Atom", "Ethereum").
This does not yet handle the "diamond problem", where a user sends a token originating on chain A
to chain B
, then to chain D
, and wants to return it through D -> C -> A
- since the supply is tracked as owned by chain B
, chain C
cannot serve as the intermediary. I don't know whether dealing with that case should be in-protocol or not - it may be fine to just require the original path of redemption (and if there is frequent liquidity on both paths it will work most of the time). Complexities arising from long redemption paths may lead to the emergence of central chains in the network topology (Hubs).
from ibc.
To-do:
- Denomination mapping
- Add more comments describing function behaviour
- Ensure interfaces all match up
- Ensure supply tracking works correctly, maintain explicit accounts per channel
- Consider irregular connection alteration
from ibc.
This will happen in 1.0.0-rc3
, not this evening.
edit: Never mind.
from ibc.
Related Issues (20)
- Use Protobuf encoding instead of JSON for the ICS20-v2 `FungibleTokenPacketData` HOT 6
- Optional field to specify relayer address for recv packet delivery HOT 3
- Achieving constant sized state bloat for unordered channels HOT 1
- ICS20: Add Denom and Trace typed structures to ics20 v2 packet definition HOT 1
- Closed channel cannot process acknowledgements
- ICS20, ICS27: Allow applications to propose version in `onChanOpenTry`
- ICS02: document querier approach for conditional clients
- ICS20: Create diagram for token forwarding
- ICS003: Remove client and consensus state validation during the connection handshake HOT 1
- ICS08: updates from using base-64 encoded bytes and different name for `path` field
- Support a packet commitment structure which contains multiple packet data's HOT 1
- IBC Transfer was constructed with bad Timeout Height and has not been received in destination chain HOT 1
- Remove usage of capabilities
- Refactor repo to place current specifications in v1 folder and create new eureka specs under v2 folder
- Modify 07-tendermint client specifications in order to also support TAO v2 spec. HOT 1
- Create 02 client spec in v2 core folder HOT 1
- Create 24-host spec for v2 with vastly limited provablestore surface area
- Port over ICS23 spec into v2 folder
- ICS4: v2 handling of packet flow
- ICS20: Support v2 TAO in ICS20 spec
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 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.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
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.
from ibc.