Skip to content
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

Accounts whitelists #468

Closed
ivandzen opened this issue Jan 20, 2022 · 0 comments · Fixed by #479
Closed

Accounts whitelists #468

ivandzen opened this issue Jan 20, 2022 · 0 comments · Fixed by #479
Assignees

Comments

@ivandzen
Copy link
Contributor

ivandzen commented Jan 20, 2022

It is required to allow using Neon Proxy only for restricted amount of clients for the Pre-Alpha/Alpha period. Such restrictions will be implemented by introducing several types of account whitelists:

  • Operator whitelist - already implemented in Neon-EVM
  • Client whitelist - set of client accounts that was approved by Neon to run transactions
  • Application whitelist - set of program accounts that was approved by Neon to deploy programs to it

Client and Application whitelists will be implemented by using special 'allowance' tokens:

  • Client allowance tokens should be transferred to selected tester accounts that was approved by Neon. Proxy will check sender of every incoming transaction to have non-zero allowance-token balance or reject transaction otherwise.
  • Application allowance tokens should be transferred to selected program accounts that was approved by Neon to deploy programs to it. Proxy will check every incoming deployment transaction to have non-zero allowance-token balance on target program account or reject transaction otherwise.

Addresses of allowance token's mints should be hardcoded into Neon-EVM. Proxy should retrieve this addresses from Neon-EVM and use it then to correctly calculate allowance-token-accounts for clients and programs

UPD:
After brainstorming it was decided to introduce additional tokens:

  • Client denial token
  • Contract denial token

Denial tokens will be used to deny some client/contract to execute transactions/deploy. Permissions for client/contract will be calculated as difference allowance-token-balance minus denial-token-balance. Received value than will be compared with preconfigured minimal-balance to make a decision: client/contract will be allowed to execute transaction/deploy if difference is greater or equal to minimal balance and denied otherwise. This approach is more flexible in case when it is required to revoke allowance for some clients/contracts. Also this approach makes it easier to test feature on different environments

Proposed test plan

┆Issue is synchronized with this Jira Task by Unito

@ivandzen ivandzen self-assigned this Jan 20, 2022
@vasiliy-zaznobin vasiliy-zaznobin linked a pull request Jan 25, 2022 that will close this issue
s-medvedev pushed a commit that referenced this issue Jan 27, 2022
* Add client allowance token

* Edit condition

* Fix address calculation. Add contract whitelists

* remove line

* Fix error

* Introduce denial tokens

* add tests

* deploy storage contract

* remove contract allowance|denial token, add minimal client|contract allowance balance

* edit log lines

* refactoring

* fix permission tokens balance requests

* add PermissionToken and UTs

* Add AccountWhitelist

* remove unnecessary file

* fix comments

* revert some changes

* use AccountWhitelist in EthereumModel

* revert address.py changes

* revert environment.py

* Add tests

* Fix

* fix

* Fix reading env variables

* Fix whitelist

* skip_preflight

* Fix after moving to solana 1.8.12

Co-authored-by: Ivan Loboda <[email protected]>
@s-medvedev s-medvedev reopened this Jan 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants