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
ZetaCore (interacting with ZEVM protocol contracts) and ZetaClient (interacting with connected chain protocol contracts) could have a declarative design to define how they interact with the protocol contract.
Right now the design is more imperative in the sense they define "parse" and "sign/call" functions for the reading inbounds and writing outbounds for each of the different interactions.
A declarative approach would be to define a single parse, sign (ZetaClient) and call (ZetaCore) function and two slices:
the events to parse for inbounds
the tx to send for outbounds
Reasoning
In the future we might make improvement in the protocol contracts: improving the interface, adding new gateway functions, etc..
While gateway contracts are upgradable for faster iteration, changes in the interface still need update in the protocol (and upgrades). This design would allow faster iteration, making changes in the repo minimal so patch releases could be performed more securely.
Going further
Explore the idea of pushing inbound events and outbound txs in the store, so new interface could be supported without upgrades.
The text was updated successfully, but these errors were encountered:
Idea
ZetaCore (interacting with ZEVM protocol contracts) and ZetaClient (interacting with connected chain protocol contracts) could have a declarative design to define how they interact with the protocol contract.
Right now the design is more imperative in the sense they define "parse" and "sign/call" functions for the reading inbounds and writing outbounds for each of the different interactions.
A declarative approach would be to define a single parse, sign (ZetaClient) and call (ZetaCore) function and two slices:
Reasoning
In the future we might make improvement in the protocol contracts: improving the interface, adding new gateway functions, etc..
While gateway contracts are upgradable for faster iteration, changes in the interface still need update in the protocol (and upgrades). This design would allow faster iteration, making changes in the repo minimal so patch releases could be performed more securely.
Going further
Explore the idea of pushing inbound events and outbound txs in the store, so new interface could be supported without upgrades.
The text was updated successfully, but these errors were encountered: