-
Notifications
You must be signed in to change notification settings - Fork 105
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
feat!: bank precompile #2860
base: develop
Are you sure you want to change the base?
feat!: bank precompile #2860
Conversation
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the WalkthroughWalkthroughThe pull request introduces a precompiled contract for managing banking operations within a blockchain environment, allowing for the deposit and withdrawal of ZRC20 tokens as Cosmos bank tokens. It includes updates to various files, implementing functions for balance inquiries, deposits, and withdrawals. Additionally, the changes enhance error handling and logging capabilities, ensuring robust interactions with the banking contract. Changes
Assessment against linked issues
Possibly related PRs
Suggested labels
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
004c3af
to
3eecbbf
Compare
977f122
to
55aaf96
Compare
4099e86
to
ab771a8
Compare
4232a98
to
05d0bfb
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #2860 +/- ##
==========================================
Coverage ? 66.52%
==========================================
Files ? 386
Lines ? 21580
Branches ? 0
==========================================
Hits ? 14357
Misses ? 6536
Partials ? 687
|
// getEVMCallerAddress returns the caller address. | ||
// Usually the caller is the contract.CallerAddress, which is the address of the contract that called the precompiled contract. | ||
// If contract.CallerAddress != evm.Origin is true, it means the call was made through a contract, | ||
// on which case there is a need to set the caller to the evm.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.
could you explain why is this set like this? if some contract is calling function and you replace caller by origin, you need to authorize all operations from origin to contract, or this is not needed?
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.
The current design expects the original caller approves the bank contract to spend X tokens on their behalf:
- EOA runs
ZRC20.approve(bankAddress, X)
, so bank can spend X ZRC20 on their behalf. - EOA calls
bank.deposit(ZRC20Addr, X)
orcontract.depositToBank(ZRC20Addr, X)
.
Open to discussions here.
} | ||
|
||
// Get the correct caller address. | ||
caller, err := getEVMCallerAddress(evm, contract) |
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.
what happens if acc -> smart contract and that smart contract calls deposit maliciously?
in that case caller is replaced with origin here and it is executed without checking that original caller authorized smart contract to deposit for account? or that is handled somehow, if that is the case i think it would be clearer to explain in comment a bit
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.
If an EOA calls some function in a malicious contract that tries to deposit in bank:
- the bank will try to transfer funds from the original caller (either if it's contract.Caller or evm.Origin)
- if the bank doesn't have allowance from the original EOA, the call fails.
- if the bank does have allowance, the new coins are minted and ZRC20 is locked in bank
- new cosmos coins are minted and sent to the original EOA cosmos address, not to the contracts.
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.
btw, in zetaclient, we have a compliance check for restricting actions for banned addresses. How can we integrate the same approach here?
3c56284
to
6271e7a
Compare
} | ||
|
||
// Get the correct caller address. | ||
caller, err := getEVMCallerAddress(evm, contract) |
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.
btw, in zetaclient, we have a compliance check for restricting actions for banned addresses. How can we integrate the same approach here?
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.
This looks good to me, I will do another more in-depth view as it is a big PR, but I think we can already work on the next steps on top of this branch in any case
Description
Closes #2791.
Implements a bank precompile, with the following functions:
WIP
How Has This Been Tested?
Summary by CodeRabbit
New Features
Bug Fixes
Documentation
Tests
Chores