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

Arc0039 - "owned by one and used by many" type of record, and their necessity #62

Open
wants to merge 10 commits into
base: master
Choose a base branch
from

Conversation

r001
Copy link

@r001 r001 commented Jan 17, 2024

ARC0039 - README.md
Discussion

Aleo is a L1 blockchain using ZK proofs. This feature enables significant scalability as contracts are run by one, and verified by many in O(1) time. This is opposed to legacy protocols where validators run code again to verify. There is a caveat though, whatever is executed in the finalize() function uses a one-time execution and a many-time execution model. This means it is only as scalable as legacy protocols. Aleo's record infrastructure is scalable. SnarkVM needs one new minor (?) feature to avoid finalize() function: in transitions, make it possible to access the public fields of records whose owner differs from the signer. In other words, we need “owned by one and used by many" types of records for transitions.

This new feature has several applications, including but not limited to:

  1. Authorization
    1. User can be authorized to use some transitions by Administrator. This can be done by the Administrator creating an Authorization record with the user's address in the public field. User can use this record (eventhough it is not owned by him) to access any desired transition.
    2. Records can also be used to authorize programs (by their addresses) to use any desired transitions by issuing Authorization records. Thus making the system more modular, secure, and upgradeable.
  2. Provide system updateable system settings
    An authority can create and recreate a record of system settings. These can be used in any transition by anyone. Once the settings are updated only the updated settings will be applicable to the next transition.
  3. Enable or disable system transitions
    The existence of a record can prove a transition is enabled or disabled. The Administrator can issue the record.
  4. Provide token prices for the system
    A records public field can be the price provided by some Oracle for a token. The record can be updated by Oracle and read by anyone.
  5. Provide UTC time for the system
    A record of the current UTC time can be consumed and recreated by a node every x minutes and read by anyone as a trusted time record.

@HarukaMa
Copy link

HarukaMa commented Jan 30, 2024

From protocol point of view, to achieve this, we will need a way to use a record without consuming it.
Also we will need a way to address records without owning them (through commitment?).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants