Arc0039 - signal records, and their necessity

[r001]

ARC0039 - README.md
Discussion

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.

[HarukaMa]

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?).

[evanmarshall]

I'm also not sure how you prove the record hasn't been spent yet. Let's say there's a user Alice who creates a record and then a different user Bob wants to use the public parts of the record.

I agree with @HarukaMa above that there's an issue to think through regarding how to spend or avoid spending this record. There's also an issue with checking that it hasn't been spent. Spending a record should only be known to the user who can generate the serial number for a record which requires the private key.

[r001]

@HarukaMa @evanmarshall I agree that the spending a record should be known only to the user. EXCEPT if the very intention of the user is the whole world to know that it was spent.
Currently Aleo only allows async composability of different contracts by mappings that do not scale. Using this infrastructure any contract can message to another in an asynchronous way.

Solution could be to allow to OPTIONALLY make the sequence number public, like any other field of the record. If user makes it private, that is the current behaviour, if public, anyone can know if the record has been spent. And if this "little" addition is done, I guarantee you will have a succesful ZeFi system: a system that is private, and a one that scales. I cant stress enough how important this "little" feature is for the success of ZeFi.

[r001]

I'm also not sure how you prove the record hasn't been spent yet. Let's say there's a user Alice who creates a record and then a different user Bob wants to use the public parts of the record.

I agree with @HarukaMa above that there's an issue to think through regarding how to spend or avoid spending this record. There's also an issue with checking that it hasn't been spent. Spending a record should only be known to the user who can generate the serial number for a record which requires the private key.

I have updated my proposal based on your comments! Highly appreciate your help!