-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Basic Client #162
Basic Client #162
Conversation
Codecov Report
@@ Coverage Diff @@
## master #162 +/- ##
===================================================
+ Coverage 51.81590% 52.05617% +0.24027%
===================================================
Files 141 143 +2
Lines 5975 5982 +7
Branches 76 77 +1
===================================================
+ Hits 3096 3114 +18
+ Misses 2581 2571 -10
+ Partials 298 297 -1
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
\*╚══════════════════════════════════════════════════════════════════════╝*/ | ||
|
||
// local chain Origin: used for sending messages | ||
address public immutable origin; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should this be enforced to be immutable at the abstract level? or should we allow the inheritor to decide if they want to have the customization ability post-facto.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Origin and Destination are supposed to have a permanent address on each chain, as they are never "unenrolled". So I thinking making them immutable on the abstract level is fine.
Ideally deployed on the same address on all chains through restricted create2 factory (just as other "system" contracts).
Restricted to prevent contract address squatting on deployed chains.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Once the "create2 factory" is up, could allocate some resources for mining salts resulting in a pretty address. A-la
https://etherscan.io/address/0x11111254369792b2ca5d084ab5eea397ca8fa48b
https://etherscan.io/address/0xdef171fe48cf0115b1d80b88dc8eab59176fee57
https://etherscan.io/address/0x00000000003b3cc22af3ae1eac0440bcee416b40
address public immutable origin; | ||
|
||
// local chain Destination: used for receiving messages | ||
address public immutable destination; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same q
Description
This PR introduces
BasicClient
, which is the most minimal abstraction of a message sender/recipient. It also adjusts existingClient
contract, by making it inherit fromBasicClient
.Basic Client
Assumptions
Security checks
BasicClient
features a function to handle incoming messages:Following statements have been checked prior to
_handleUnsafe()
:Destination
contract.No checks are done for the merkle root timestamp, this allows app to have a flexible optimistic period for different type of messages. Function is named
_handleUnsafe
to keep dev's attention to the fact that optimistic period needs to be enforced.Client
Assumptions
Client
).Security checks
Client
features a function to handle incoming messages:Following statements have been checked to
_handle()
:Destination
contract.