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

ARC-0039 - signal records, and their necessity #62

Open
wants to merge 20 commits into
base: master
Choose a base branch
from
Prev Previous commit
Next Next commit
README.md
  • Loading branch information
r001 committed Jan 11, 2024
commit e6317bf205fa2b150a64959c4e5cd4927a48d9da
36 changes: 34 additions & 2 deletions arc-0031/README.md
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
---
arc: 0031 # Add the next sequence number
arc: 0039 # Add the next sequence number
title: Records that are created by one and read by many # Title
authors: Robert Horvath rob@nyar.eu # Add all Github usernames, emails, and/or full names
discussion: # Create a 'Github Discussion' titled 'ARC-XXXX: {TITLE}`
Expand All @@ -10,7 +10,8 @@ created: 01/15/2024 # Date

## Abstract

Aleo has a huge leverage over other projects by applying ZK proofs on L1 level. Applying ZK proofs enables great scalability as contracts are run by one and verified by many in O(1) time, as opposed to other protocols where many has to execute code again to verify. There is a caveat though, whatever is executed in the `finalize` function uses one executes and many executes again model which means it is as scalable as legacy protocols. The record infrastructure of Aleo makes it scalable, but some minor (?) change is needed in snarkVM: allow the use of any public fields of records with any `owner` within a transition. With other words: we need "create by one and read by many" types of records usable in transitions.
Aleo has a huge leverage over other projects by applying ZK proofs on L1 level. Applying ZK proofs enables great scalability as contracts are run by one and verified by many in O(1) time, as opposed to other protocols where many has to execute code again to verify. There is a caveat though, whatever is executed in the `finalize` function uses one executes and many executes again model which means it is as scalable as legacy protocols. The record infrastructure of Aleo makes it scalable, but some minor (?) change is needed in snarkVM: allow the access of any public fields of records with any `owner` within a transition. With other words: we need "create by one and read by many" types of records usable in transitions.

It has several applications, including but not limited to:
1. Authorization:
1. a record issued by an issuer can be used as a proof of authorization for a transition. Owner is the issuer, and the public field of the authorized address can be used by that address to access the transition.
Expand All @@ -21,6 +22,37 @@ It has several applications, including but not limited to:

## Specification

![Current Tx Logic](./images/arc39-current.png)
**Figure 1: Current Transition Logic**

In **Figure 1** user 1 is the signer of the transition.

As **Figure 1** shows, the current transition logic is the following:
1. If the transition has only the type of records that are owned by the caller, then the transition is executed.
2. If any of the input records are not owned by the caller, then the transition is not executed. Even if the record has public fields that otherwise should be accessible.


![Proposed Tx Logic](./images/arc39-proposed.png)
**Figure 2: Proposed Transition Logic**

In **Figure 2** user 1 is the signer of the transition.

As **Figure 2** shows, the proposed transition logic is the following:
1. If the transition has only the type of records that are owned by the caller, then the transition is executed. Just like in the current logic.
2. If the input of the transition is a mix of records owned by the caller and not owned by the caller, then:
1. All the public fields of the records owned by the caller are accessible in the transition. Just like in the current logic.
2. All the private fields of the records owned by the caller are accessible in the transition. Just like in the current logic.
3. All the public fields of the record not owned by signer are accessible in the transition. **DIFFERENT from the current logic!**
4. Accessing any private fields of the record not owned by signer will result in an error. **DIFFERENT from the current logic!**
5. Not accessing any fields of a record that is not owned by signer should be allowed. **DIFFERENT from the current logic!**
This is needed for allowing the execution of certain transitions. The very existence of the record is the proof of the transition being enabled. The transition must fail if the record is not present.

### Use Cases

#### Authorization Record

![Proposed Tx Logic](./images/arc39-authorization.png)


<!-- Define key terminology here. -->

Expand Down