ARC0039 - Records that are owned by one and used by many

[r001]

README.md

Aleo blockchain is both programmable and encrypted, positioning itself as a unique platform in the increasingly crowded DeFi market. With the current market saturation, gaining traction in this space is becoming more challenging. To stand out and attract significant players from traditional financial institutions, Aleo must introduce scalability as well to its DeFi applications. This proposal aims to unlock this potential by introducing a new type of record: signal records.

Signal records are designed to provide publicly readable information while ensuring that creation and consumption are restricted to a single entity. This feature is crucial for enabling scalable, secure, and efficient operations on Aleo's platform, making it more attractive to large financial institutions.

Key Benefits of Signal Records:

• Scalability: Signal records enable high-performance management of smart contract states, ensuring that Aleo's platform can handle large-scale operations efficiently.
• Flexibility: Developers can utilize signal records for a variety of applications, including the announcement of UTC time - a necessity for DeFi, authorization, and dynamic system settings.
• Security: The design of signal records enhances privacy and ensures that sensitive data remains protected.
• Resource Efficiency: By allowing for more efficient use of Aleo's resources, signal records reduce operational costs for both users and validator operators.

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

1. Scalable smart contract state (both private and public)
   Smart contract can create and recreate one or several signal record(s) of smart contract state. 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.
2. Provide UTC time
   A signal 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 signal record. For DeFi apps a reliable UTC time source is a must.
3. Authorization
   1. User can be authorized to use some transitions by the 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. Signal 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.
4. Enable or disable transitions
   The existence of a signal record can prove a transition is enabled or disabled. The Administrator can issue the signal record.
5. Provide token prices
   A signal records public field can be the price provided by some Oracle for a token. The signal record can be updated by Oracle and read by anyone.

[vicsn]

Thank you so much for your contribution. Would love to give as much technical guidance as possible to realize the vision of scalable and private DeFi.

Given that the primary advertised benefit involves public state, I'm curious to understand better why the existing public program mappings are not sufficient for some concrete usecase. Noting:

• for the time, why is it not sufficient for a transition to read a finalize mapping?
• authorization to use some transition can be enabled in a more roundabout way by using a mapping, read during a transition's corresponding finalize context. Maybe some Leo syntax sugar can help.

[r001]

Hi @vicsn,
Thanks for the interest.

To give you some context: we are working on a stablecoin solution for Aleo called PayPer because I did the same with MakerDao back in 2017. As market for DeFi products is increasingly competitive, we must be able to show to our customers what we can do better than the competition. Aleo using records can offer a salable solution: validators can accept results based on validating one single zero knowledge proof, no consensus, and no code re-run needed on behalf of validators for a transaction. But Mappings on the other hand behave the same way as legacy products: validators need to rerun all the code that deals with mappings, thus this operation will not scale, and will be 10 times more expensive at start of mainnet.

So the purpose of this proposal is to create a successful DeFi space on top of Aleo by leveraging the potential scaling properties of it. My experience that it is not enough to offer the market the same as anyone else can do, and in DeFi privacy over pseudonymity offered by Ethereum is not that of a big offer. But privacy with scaling is. I have a really bad experience at Radixdlt.com where I used to work too: they have created a wonderful smart contract experience, with brilliant people, it is SORTOF more scalable than Ethereum, because of smart sharding. But this was not enough for the market, there is no vivid DeFi life on top of it, so the network token price goes down in freefall. To survive we must offer big. That is my experience.

From a programming perspective: whenever you encounter finalize or the new async blocks in the code, those parts won't scale. All mappings-related functions need to be in those blocks, meaning mappings themselves won't scale. If we can handle everything using records instead, we can achieve scalability, deliver a key advantage to our users, and succeed.

And I agree with you that this feature is not to be included to current mainnet. But right afterwards in the first update. And you will see the DeFi on Aleo flourish, and Aleo price going up to the roof, thus Aleo developers have a long term place to be.

[vicsn]

I see, I'm starting to get excited.

My apologies, instead of 'concrete usecase' I was really trying to ask for an as basic possible Alice and Bob example. Your README seems like a great and very comprehensive spec, but its hard for me to see the forest through the trees. Could you give a single simple realistic example of an example signal record (with e.g. a public timestamp field) and how you envision it being used by a transition?

My current thoughts:

1. If the program requires retrieving public data from validator's disk (whether its in a mapping or record), it won't scale
2. If the program takes in a public record id (the contents of which are checked using a ZKP), there is still a disk read for the record id, so that might only be faster if the record contains lots of data to use by the program.

• Alternative idea: create a commit.verify finalize opcode. Also note that a finalize hash fundamentally is faster than zkp verification.

3. If the program takes in a private record id (both contents and record inclusion are checked using a ZKP), then there is no disk read, but this might require validators to do an extra ZKP verification.

I can look into whether 3. is possible. Whether 2. is useful depends on how much data your exact usecase needs.

[r001]

Sure,

Simplified Alice and Bob Example Using Signal Records

Scenario:
Alice wants to set the current UTC time as a public signal, which Bob can then use to calculate interest on the Aleo blockchain.

Steps:

1. Alice Creates a Signal Record (Time Record):

   • Alice creates a signal record called TimeRecord with a public field that contains the current UTC time.
   • This record is owned by Alice, but the public field (which contains the UTC time) is accessible to anyone.

   signal_record TimeRecord {
       public utc_time: u64,
       owner: address 
   }
   

2. Bob Uses the Time Record in a Transition:

   • Bob wants to perform a transition that requires a trusted timestamp. Instead of generating or storing the time locally, Bob references the TimeRecord created by Alice.
   • In the transition, Bob accesses the public UTC time from the TimeRecord to calculate interest on his loan.

   record LoanRecord {
       private amount: u128,
       private receive_date: u64,
       private interest_rate: u128,
       owner: address
   }
   

   transition calculate_interest( 
       TimeRecord {..., owner: Alice},
       LoanRecord {..., owner: Bob}
       ) -> u128 //interest 
    {...}
   

3. Verification and Execution:

   • The transition checks the TimeRecord’s public field to ensure the timing is correct.
   • Because the TimeRecord is a signal record, Bob does not need to own it; he can simply reference its public data.
   • Bob can't cheat, as the time record can not be forged by him.
   • If TimeRecord has been consumed, Bob will not be able to use it anymore, and must use the new official TimeRecord.
   • The transition returns the interest based on the two records.
     Note: currently any transition would automatically fail with the setup above, as the owner of TimeRecord is different from Bob, the signer of the transition (it is Alice).

Concerning your thoughts:

1. I agree what you wrote there, except for mappings. If you use mappings, the system will have to initialize and run the virtual machine, and execute THE WHOLE program concerning the mapping(s) on ALL validators. This is not just one data read, but a whole bunch of data reads, even if you read one single u128 from a mapping, and a lot of CPU resource.
2. In case of records only one (or more) simple zKP check which is constant time (no matter how long your transition code executes). One memory read per data field (and it is probably optimizable too in the future).

So key takeaways for Signal Records:

• Scalable: using Signal Records takes much less resource from the system, making it less CPU and RAM intensive, making it (more) scalable.
• Resource Efficient: Currently the pricing to access a record field vs. access a mapping field is 1 to 10. And it is so for the reason above.