docs: Merge the constitution and the definition UTXOs.

[SWvheerden]

Description

This creates a proposal to merge the ContractDefinition and ContractConstitution UTXOs into a single Constitution UTXOs governing all of the contract.

Motivation and Context

Currently the RFC states we have two UTXOs, one for defining the contract and one for controlling how its governed. This is a proposal to merge the two into a single UTXO that lives with and can be updated with the contract life of the asset.

This requires that all information in the ContractDefinition be stored with the ContractConstitution. This is still less data that lives on-chain as we don't require the kernels of two UTXOs, but the actual data contained in them is still the same.

The biggest requirement of the ContractDefinition UTXO is to identify the contract and its contract_id. By merging the two we need an extra base layer consensus rule to ensure that the contract_id and its construction fields remain the same across constitution changes.

The new contract_id is defined as: H(contract_name || asset issuer record). asset issuer record is just using a field that is useful for recording purposes as random entropy so we can have duplicate contract_names.

The advantage of going this route is that we have fewer UTXOs needed to manage and run a contract. Although the current RFC is still out of date and states that the ContractDefinition UTXO is spendable, this has been changed to make it static. In practice this makes that the MMR of the entire blockchain will not be prunable after the first ContractDefinition UTXO has been mined. The UTXO set will still be prunable, but not the MMR.

[sdbondi]

I think this makes sense. Though perhaps the UTXO is now the definition and we do away with the constitution naming.

[brianp]

I think originally we had planned to put the script inside the contract, and eventually moved that out to the constitution as well to make it easier to update. Which really left nothing by the contract id in the contract definition. So I think now having this all as a single transaction, and hashing the id based on specific fields from it makes sense to me. I don't see a need to require both the definition, and constitution when one would do.

[brianp]

As per the Thursday technical discussion on July 30th, we've removed the initial reward. VN's will not receive an initial reward and we simplify the UTXO needs.

[brianp]

Additionally the emergency keys, and asset owner can spend checkpoints under specific conditions.

[brianp]

@sdbondi

do away with the constitution naming

I think its purpose was sugar for human readability, and we wanted it static overtime to reduce possible confusion.

[CjS77]

I vote to keep them separate. It's not an oversight that the current RFC is written this way.

The contract (what code is being run) and the constitution (how the code is managed) are disparate enough concepts that they warrant separate entries on the blockchain.

We want to keep a queryable index of live contracts, and a queryable index of constitutions. Keeping these separate simplifies the database management. The cost in terms of storage space is worth the trade-off IMHO.

Moreover, the contract definition very seldom changes, if ever. It should be treated as near-immutable. If this UTXO is spent, observers know that the code governing the contract (i.e. the contract itself) has likely changed, and this can and should fire off all sorts of red flags.

I'd argue that constitutions will change an order of magnitude more frequently than the contract, so merging the two means that observers must do many more checks on the contract code than they otherwise would need to.

[SWvheerden]

I vote to keep them separate. It's not an oversight that the current RFC is written this way.

The contract (what code is being run) and the constitution (how the code is managed) are disparate enough concepts that they warrant separate entries on the blockchain.

We want to keep a queryable index of live contracts, and a queryable index of constitutions. Keeping these separate simplifies the database management. The cost in terms of storage space is worth the trade-off IMHO.

Moreover, the contract definition very seldom changes, if ever. It should be treated as near-immutable. If this UTXO is spent, observers know that the code governing the contract (i.e. the contract itself) has likely changed, and this can and should fire off all sorts of red flags.

I'd argue that constitutions will change an order of magnitude more frequently than the contract, so merging the two means that observers must do many more checks on the contract code than they otherwise would need to.

What do we do with versioning of code, do we not lock that in as well? That will almost definitely update. Then we need to update this.

The only reason I am against them separately is the MMR prunability.

Here is the current rfc for the templates:
#2

[CjS77]

Yes, and a code version update is

1. exactly what people will be looking to audit
2. happen much less frequently than constitution changes for the vast majority of contracts

[SWvheerden]

Who do we give ownership of this, the CC or the asset issuer?
Thinking CC?

[CjS77]

The asset issuer basically ceases to be relevant after the contract initialisation.

If the AI does not add themselves to the CC they basically relinquish any and all control of the contract.

edit: I see what you're doing here :)

You're saying if the CC determines whether a contract can be upgraded, then we need to refer to the constitution anyway to determine if a contract update is valid or not. If that's the case, why not simply include the contract definition into the constitution.

There's another consideration. Bob is the template author for a contract. He release v1 which our contract is based on. Bob upgrades the template to v2. The contract is not forced to upgrade to v2. They can stay on v1 if they like.

[CjS77]

I see no point in spending effort to resolve conflicts when this RFC will be deprecated soon in favour of a better proposal being developed by the community, so just going to close it.