AleoNet
ARC-0080: Explicitly Reject Program Address as Record Owner
The current Aleo system permits the assignment of a Record to any address, including program addresses. However, programs cannot spend a Record. Consequently, any Record assigned to a program becomes irretrievable, leading to unintended asset loss in Aleo, which can include credits, tokens, NFTs, and more. With the introduction of arc-0030, which enables Aleo users to transfer assets to a program, the frequency of such incidents is likely to increase.
This proposal seeks to explicitly prohibit the creation of a Record with a program as the owner, significantly reducing the potential for asset loss.
The only way to differentiate "program address" from "real address" would be to track all program names and their addresses. I'm not sure that's what you meant here.
Also, aleo1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqquzlzl is not even a valid address - it has wrong bech32 checksum.
The only way to differentiate "program address" from "real address" would be to track all program names and their addresses. I'm not sure that's what you meant here.
I think there are several ways we can take to differentiate "program address" from "user address":
-
Distinguish addresses within the protocol: Add one-byte prefix to specify the type of the address. For example, the type of "user address" is
0x00and the type of "program address" is0x01. While creating new record ensure the type of the owner address is0x00. This may need some changes in the circuit and the synthesizer. -
Only locally check the address while generating
Transition: While locally generatingTransition, if a record is created, ensure the record owner is not an already deployed program. This can be done efficiently by applying bloom filter. -
Label the type of
self.callerwhile executing the transaction: While executing a transaction, internally label the type ofself.caller. Then ensure a program address can't be the owner while creating a record. This won't prevent the case that the user input a program address as constant, which I think is less likely to happen.
I prefer method 3 because it has a lower impact on the existing codebase and just needs to add labels and checks in the execution.
Does it mean that we cannot transfer credits into contract and distributed by program logic?
@AidenZuk For public credits or any mapping data: it's possible, provided that the storing program knows what to do (e.g. properly uses self.caller); for records: don't do that.
@AidenZuk For public credits or any mapping data: it's possible, provided that the storing program knows what to do (e.g. properly uses
self.caller); for records: don't do that.
Okay, It's clear now. Thanks very much
Can you please put a link to the rendered version of this Arc in the PR description?
Can you please put a link to the rendered version of this Arc in the PR description?
Done.