Why ordering of inputs and outputs can' be deterministic

[crisdut]

I found a bug during the Sonic project review:

I noticed that the GenesisID changes according to the order of data added when issuing a contract.

After investigating, I noticed that the immutable and destructible fields, used in Genesis CommitmentId, are of type SmallVec., i.e, we have no ordering guarantees.

We could use the TinyOrdMap type, for example, to guarantee that regardless of the order of the entries, we will produce the same GenesisID, which consequently makes the same ContractID.

To reproduce the error, use the two YAMLs I added below. In them, I reversed the order of the circulating fields in them.

sealType: BitcoinOpret
codexId: znwQGVhW-rfRa8el-pNaAsUW-UWxXsB_-4UlC~Tf-TERhBm4#mirage-queen-delphi
name: DemoToken
method: issue
timestamp: "2024-12-18T10:32:00-02:00"

global:
  - name: circulating
    verified: 10000
  - name: name
    verified: Demo Token
  - name: ticker
    verified: DEMO
  - name: precision
    verified: centiMilli

owned:
  - name: owned
    seal: b7116550736fbe5d3e234d0141c6bc8d1825f94da78514a3cede5674e9a5eae9:1
    data: 10000

sealType: BitcoinOpret
codexId: znwQGVhW-rfRa8el-pNaAsUW-UWxXsB_-4UlC~Tf-TERhBm4#mirage-queen-delphi
name: DemoToken
method: issue
timestamp: "2024-12-18T10:32:00-02:00"

global:
  - name: name
    verified: Demo Token
  - name: ticker
    verified: DEMO
  - name: precision
    verified: centiMilli
  - name: circulating
    verified: 10000

owned:
  - name: owned
    seal: b7116550736fbe5d3e234d0141c6bc8d1825f94da78514a3cede5674e9a5eae9:1
    data: 10000

Thanks

[dr-orlovsky]

Yes, that is an intendent behaviour. We have the same in RGB all previous versions, as well as in bitcoin - or any other transactions.

Ordering of intputs and outputs is a part of non-deterministic Turing machine, as well as the graph of transactions.

If it were made in a deterministic order, we for instance would never have Opret scheme.

There is no point of having inputs or outputs in any transaction-based distributed system to be a map and not a vec, where the order is set not by an algorithm but by a willing agent external to the system

[crisdut]

I understood.

I had this doubt, given that simply manipulating the order of fields (name, ticker, etc.), even containing the same information, could generate a different contract could be a problem.

This is especially true if you consider scenarios where we store the contract data in a database table, where each piece of information would be in a column. But in the end, it's up to the developer to worry about this.