ARC-0039 - 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!

[d0cd]

@r001 thank you for the submission!
We're working on revamping the ARCs process and resolving past proposals.
To that end, is this effort still active?

We plan to either close or refresh this PR on February 10th, 2025.

[r001]

@r001 thank you for the submission! We're working on revamping the ARCs process and resolving past proposals. To that end, is this effort still active?

We plan to either close or refresh this PR on February 10th, 2025.

Hi,
I think signal records would tremendously increase the usage of the Record logic of the Aleo network, because it makes the asynchronous messaging between smart contracts possible.
So Yes, it is still active.

Best
Robert

[evanmarshall]

How is a public record different from a mapping?

It seems like the only difference is the ability to pass it directly to a transition. But a transition can always take arguments and check them in the finalize against a mapping.

[r001]

How is a public record different from a mapping?

It seems like the only difference is the ability to pass it directly to a transition. But a transition can always take arguments and check them in the finalize against a mapping.

Your statement is almost true. In case of public record you do not need a finalize block at all and this might be a difference. My original motivation was to do this proposal, is that I found that there was not possible to use any messaging via records from one contract to an other only via very expensive mappings.

My question is how much more expensive is it to store an info in mappings than in records. Correct me if I'm wrong, but If we do with mappings a VM must be fired at each validator O(n) difficulty for each assert() statements at least, while a record operation only requires an O(1) check. With mappings we put a lot of weight on the Validators. So I think it should be much more efficient to use records wherever we can. I really need a feedback of how much my statement is true. I think the longer the code in the finalize() the more effective it would be to use public records.

For mappings that update frequently it is not feasible to write the logic in the transition but in the finalize() because too many users will have failed transitions because they use a meanwhile already outdated value. I end up most of my codebase in the finalize(). While using records you can create a lazy system of aggregating results, all without having to use the costy finalize().

Question do we have a calculation how much more costy is for us to put a peice of code in the transition or the same code in the finalize() block?

If mappings and the associated code uses the same or less resources as records then this proposal is not needed.