You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Implement unordered channels, with causally independent packet timeouts
Investigate feasibility of DAG ordering on individual packets (including cross-chain)
Hunch: more reliable channel ==> efficient acknowledging for multiple messages
Unordered channel ==> selective acknowledgement with message hash
Packet identities are hash of contents & predecessors, can assume ordering of receipt
Think about possible fairness guarantees across channels on a connection (maybe for v2)
Fairness across set of connections
Fairness across set of channels on a connection
We can at most restrict validator ordering choices
Priority of given message determined by sender
Clarify IBC relayer module interface, note that it is recommended to users
Optional acknowledgements of success / failure for packets
Module can choose whether or not to register acknowledgement handler
Can tell that no reaction will take place, so don't bother acknowledging
Close "reason" for channels
Reason as bytestring for voluntary closure provided by channel
System-level reasons for closure (maybe modules can register hooks)
Think about cryptoeconomics
Think about multi-hop case, construct data structures accordingly (e.g. channels are end-to-end)
Distinguish between multi-hop, single-hop in data structures, multi-hop not yet supported
Maybe trivial "IBC routing" module, maybe it handles loopback
Review IBC interface for use "slotting in" as VatTP in Agoric's protocol
Write specification-compliance testsuite with full spec coverage
Some level of "binary datagram" -> "binary datagram[s]"
How to define testsuite, parse JSON
The text was updated successfully, but these errors were encountered:
Timeouts should close ordered channels
Implement unordered channels, with causally independent packet timeouts
Investigate feasibility of DAG ordering on individual packets (including cross-chain)
Hunch: more reliable channel ==> efficient acknowledging for multiple messages
Unordered channel ==> selective acknowledgement with message hash
Packet identities are hash of contents & predecessors, can assume ordering of receipt
Think about possible fairness guarantees across channels on a connection (maybe for v2)
Fairness across set of connections
Fairness across set of channels on a connection
We can at most restrict validator ordering choices
Priority of given message determined by sender
Clarify IBC relayer module interface, note that it is recommended to users
Optional acknowledgements of success / failure for packets
Module can choose whether or not to register acknowledgement handler
Can tell that no reaction will take place, so don't bother acknowledging
Close "reason" for channels
Reason as bytestring for voluntary closure provided by channel
System-level reasons for closure (maybe modules can register hooks)
Think about cryptoeconomics
Think about multi-hop case, construct data structures accordingly (e.g. channels are end-to-end)
Distinguish between multi-hop, single-hop in data structures, multi-hop not yet supported
Maybe trivial "IBC routing" module, maybe it handles loopback
Review IBC interface for use "slotting in" as VatTP in Agoric's protocol
Write specification-compliance testsuite with full spec coverage
Some level of "binary datagram" -> "binary datagram[s]"
How to define testsuite, parse JSON
The text was updated successfully, but these errors were encountered: