Missing parts in bundle method

[crisdut]

Description

Version: v0.12 (74ce5ce) (https://github.com/RGB-WG/rgb-std/tree/refactor/consensus)

I think there are some "missing steps" in the bundle method:

• Missing "blank" method Api: The "_" (blank) method, used in this piece of code, is not defined in the APIs used in the NIA and CFA Codices [1].

• Missing "change" step: A sub-routine within the bundle method, which obtains the operation inputs and calculates the "change" of the contract state using EmbeddedCalc (For now, provide by Codex API) , must be implemented.

[1] I was wondering whether this method needs to exist in the API since it has no relation to the contract itself but rather the need to update the other contracts linked to UTXO. In this case, should we replace this call with some method that directly constructs a state?

[dr-orlovsky]

I was wondering whether this method needs to exist in the API since it has no relation to the contract itself but rather the need to update the other contracts linked to UTXO. In this case, should we replace this call with some method that directly constructs a state?

This is standardness, not consensus. Contract devs must provide this method, otherwise contract state will be lost. Since there are many ways how contract devs may fuck up their contracts (like invalid validation code), it is fine.

Assigning multiple seals to the same UTXO is just a feature of Bitcoin and Liquid (Prime doesn't have it). Thus, not even all contracts would need it.

Combination of blank verifier _ and calculator allows to combine blank state transitions with aggregation.

[dr-orlovsky]

BTW both points are not related to this repo. (1) belongs to https://github.com/pandora-prime/rgb-issuers, but there is no code yet; just a template/placeholder. (2) belongs to https://github.com/AluVM/sonic/

I am converting this into a discussion rather than issue

[crisdut]

BTW both points are not related to this repo.

Yes, I agree.

I prefer to open it here, because that's where I "found the problem", and I thought if I opened issues, it might end up being more confusing.

(1) belongs to https://github.com/pandora-prime/rgb-issuers, but there is no code yet; just a template/placeholder.

Ok, sure.

(2) belongs to https://github.com/AluVM/sonic/

Despite your comment above, I imagined that the subroutine should stay in the bundle itself, given that sonic is already providing the necessary features to build this state.

I am converting this into a discussion rather than issue

As version 0.12 is being built, would you prefer me to open discussions instead of issues?

I ask this because I believe some issues may be more "doubts" than errors at this stage. Additionally, it is a means of "documenting" review decisions and insights.

What do you think?