Open Farhad-Shabani opened 1 year ago
The recent refactoring of TokenTransferReader/Keeper to TokenTransferValidation/ExecutionContext revealed that there is a potential for host chain objects implementing core contexts to expand their capabilities by also implementing token transfer contexts.
They can but they don't have to. Both basecoin-rs and Namada implement Module
on a separate object from the one that implements Validation/ExecutionContext
.
This mixes distinct concerns under the core context and limits IBC implementation to only support one transfer module.
Our current architecture allows chains to have as many transfer modules as they want; only one can be bound to the transfer
port though (as mandated by the protocol).
and for the core, it does not matter what's the content of a packet's data! that's right; our implementation of ibc-core currently is agnostic to the contents of packets. Can you expand on why you think that is not the case?
Problem Statement
The recent refactoring of
TokenTransferReader/Keeper
toTokenTransferValidation/ExecutionContext
revealed that there is a potential for host chain objects implementing core contexts to expand their capabilities by also implementing token transfer contexts.However, this approach is incorrect (which already has been applied to the
MockContext
). This mixes distinct concerns under the core context and limits IBC implementation to only support one transfer module. Considering that the IBC core only operates applications by callingon__*__validate/execute
methods under theModule
trait, the token transferring or any other apps should be a capability of a module object! and for the core, it does not matter what's the content of a packet'sdata
!To prevent incorrect implementation, improve modularity, and clarify the role of each, It is suggested to bind
TokenTransferValidation/ExecutionContext
with a newly definedModuleContext
(As we execute issue #519, some methods might be gather-able underModuleContext
). This also can be bounded by the currentModule
trait. Additionally, theModule
trait can be split into two:ModuleOnValidation
andModuleOnExecution
, further clarifying their respective roles.This is an initial proposal, and as we work on issue #519, better ideas may arise. Nonetheless, the ultimate goal is to clearly differentiate module-specific contexts.