Add support for smart contracts in BNS & Atlas

[Zk2u]

Is your feature request related to a problem? Please describe.

DAOs will want to use websites and decentralised services. This will have to happen through onchain transactions as well as participants of the smart contract adding

Describe the solution you'd like

We should have the ability for smart contracts to send hashes of zone files, and real users to then upload said hash to Atlas.

While this doesn't use the Ed25519 system in Atlas, BNS can trustlessly return the hash of the zone file (as I believe it does already?) for use in Atlas. Of course, the contract wouldn't be able to upload the full zone file itself, but users of the smart contract could.

Take Syvita for example - we will want to own a BNS name for our website and public central services without using a multsig. We could build in functionality to our DAO kernel that someone can propose a change to the zone file, and with a majority vote the smart contract will trustlessly update the hash on the BNS contract. Members who proposed the change or supported it would then upload it to Atlas, which would confirm they are uploading the correct zone file that was specified by the onchain operation. This is then propagated through the network and can be retrieved by anyone through their node - usable alike a regular BNS name, just not owned by a single person.

Describe alternatives you've considered

None

Additional context

We could try get this in for Stacks 2.1, if possible. I believe it would require changes to both BNS and Atlas.

[jcnelson]

We should have the ability for smart contracts to send hashes of zone files, and real users to then upload said hash to Atlas.

The infrastructure for this already mostly exists -- we shouldn't need to wait until Stacks 2.1 for it to go live. The Atlas system already provides a way for contracts to emit events that register new attachment hashes. When you submit a contract-call transaction to that contract, you can include an attachment to be stored when the transaction is processed and the "store attachment" event is emitted (see the name-update method in BNS for an example -- the event is emitted as a sequence of print statements). The system will then try and contact other nodes to replicate the attachment if it is accepted by a particular block.

Right now, the system only pays attention to events emitted from BNS. A few changes will need to be made in Atlas to support other contracts:

• The config file needs to allow the user to specify a whitelist of contracts whose attachment events will be considered.
• The attachment replication protocol needs to be able to work with other nodes who track different contracts.

The second point is more challenging, and will require revisiting the way in which attachment inventories are represented and stored. In particular, the /v2/attachments/inv endpoint will likely need to take a contract identifier as an optional argument (the default being the BNS contract ID), so that the returned attachment page indexes returned will refer only to page indexes for the specified contract (or 404 if the contract's attachments are not tracked by the remote node). Additionally, the attachment downloader state machine will need to be updated so it runs one state machine instance per whitelisted contract, so that each contract's state (and remote neighbor set) will be requested and considered separately in the event that different neighbors track different contracts. cc @lgalabru

[Zk2u]

This is awesome.

Does Icebox mean you're planning it, then?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically closed. Please reopen if needed.