aluVM Assembly beginner has a problem with two lds with different contents. Don't know what's wrong.

[EthanShang8989]

I encountered an issue while trying to transfer an RGB21 asset. The problem arose because the token index for the RGB21 asset was 2. As a result, I set the amount in the invoice to 2, otherwise, I would receive an error message stating 'the allocated token has an invalid index'. However, even after making this change, the error persisted. So, I carefully inspected the situation and discovered the following details. I have a feeling that if the 'lds' instruction could load the same data, it might possibly pass the validation

@000000: ldg     0x0836,0,s16[1]         ; -> s16[1]=02000000010455444154010755444174657374000104746578740105706c61696e0013006269746c6967687420726762323120746573740105696d6167650103706e6700b9bf23a30bedcc4c7e5b7e83412f8962ed33012dbb822a15fb536e5f2fbf9d280000
@000005: put     a16[0],0                ; -> a16[0]=0
@000009: extr    s16[1],r128[1],a16[0]   ; s16[1]=02000000010455444154010755444174657374000104746578740105706c61696e0013006269746c6967687420726762323120746573740105696d6167650103706e6700b9bf23a30bedcc4c7e5b7e83412f8962ed33012dbb822a15fb536e5f2fbf9d280000 a16[0]=0 -> r128[1]=0x74414455070154414455040100000002
@000012: spy     a32[0],r128[1]          ; r128[1]=0x74414455070154414455040100000002 a32[0]=~ -> r128[1]=~ a32[0]=2  st0=false 
@000015: lds     0x0FA0,0,s16[1]         ; -> s16[1]="<020000000100000000000000>"//this
@000021: extr    s16[1],r128[1],a16[0]   ; a16[0]=0 s16[1]="<020000000100000000000000>" -> r128[1]=0x100000002
@000024: spy     a32[1],r128[1]          ; r128[1]=0x100000002 a32[1]=~ -> r128[1]=~ a32[1]=2
@000027: eq.n    a32[0],a32[1]           ; a32[1]=2 a32[0]=2 ->  st0=true
@000030: jif     0x0028                  ; -> 40
@000040: put     a16[0],4                ; -> a16[0]=4
@000044: extr    s16[1],r128[1],a16[0]   ; a16[0]=4 s16[1]="<020000000100000000000000>" -> r128[1]=1  st0=false
@000047: spy     a64[1],r128[1]          ; a64[1]=~ r128[1]=1 -> r128[1]=~ a64[1]=1  st0=true 
@000050: put     a64[0],1                ; -> a64[0]=1
@000054: eq.n    a64[0],a64[1]           ; a64[1]=1 a64[0]=1 ->
@000057: put     s16[0],"owned<20>fraction<20>is<20>not<20>1"; -> s16[0]="owned<20>fraction<20>is<20>not<20>1"
@000063: ret                             ; -> execution stopped; st0=true
@000064: ldp     0x0FA0,0,s16[1]         ; -> s16[1]="<020000000100000000000000>" 
@000070: jmp     0x0005                  ; -> 5
@000005: put     a16[0],0                ; -> a16[0]=0
@000009: extr    s16[1],r128[1],a16[0]   ; s16[1]="<020000000100000000000000>" a16[0]=0 -> r128[1]=0x100000002  st0=false
@000012: spy     a32[0],r128[1]          ; a32[0]=~ r128[1]=0x100000002 -> r128[1]=~ a32[0]=2
@000015: lds     0x0FA0,0,s16[1]         ; -> s16[1]="<0200000000000000>" //this
@000021: extr    s16[1],r128[1],a16[0]   ; a16[0]=0 s16[1]="<0200000000000000>" -> r128[1]=2
@000024: spy     a32[1],r128[1]          ; r128[1]=2 a32[1]=~ -> a32[1]=2 r128[1]=~  st0=true
@000027: eq.n    a32[0],a32[1]           ; a32[0]=2 a32[1]=2 ->
@000030: jif     0x0028                  ; -> 40
@000040: put     a16[0],4                ; -> a16[0]=4
@000044: extr    s16[1],r128[1],a16[0]   ; s16[1]="<0200000000000000>" a16[0]=4 -> r128[1]=0  st0=false
@000047: spy     a64[1],r128[1]          ; a64[1]=~ r128[1]=0 -> r128[1]=~ a64[1]=0  st0=true
@000050: put     a64[0],1                ; -> a64[0]=1
@000054: eq.n    a64[0],a64[1]           ; a64[1]=0 a64[0]=1 ->  st0=false
@000057: put     s16[0],"owned<20>fraction<20>is<20>not<20>1"; -> s16[0]="owned<20>fraction<20>is<20>not<20>1"
@000063: ret                             ; -> execution stopped; st0=false
Validation failures:
- invalid owned state value in operation 30a7a90aed8375ad44771c4af3708088f3e06a735ee79d58a925d52754aab8ce, state type #0x0FA0 which does not match semantic type id urn:ubideco:semid:2eQfG13SrdSq4UVbEUCA3V5Sybt72FJBBFYBs6ZU63ZS#igor-baboon-leonid.
- operation 30a7a90aed8375ad44771c4af3708088f3e06a735ee79d58a925d52754aab8ce is invalid: owned fraction is not 1

The previous are"@000015: lds 0x0FA0,0,s16[1] ; -> s16[1]="<020000000100000000000000>"'.
However the last one was"@000015: lds 0x0FA0,0,s16[1] ; -> s16[1]="<0200000000000000>"'.

[dr-orlovsky]

@crisdut seems there might be an issue with the validation code for RGB21. I am bit struggling to understand what's going here... Can you also take a look?

PS. We really need Contractum, writing and debugging in assembly is absolute PITA

[crisdut]

@crisdut seems there might be an issue with the validation code for RGB21. I am bit struggling to understand what's going here... Can you also take a look?

Hi @EthanShang8989 and @dr-orlovsky

Although the RGB21 schema allows us to add any value in tokenIndex and fraction, today, we have only UDA (Unique Digital Asset) Iface impl, (i.e., fraction needs to be equal to 1, always). There is an issue open related to that here.

The error you reported @EthanShang8989 ("the allocated token has an invalid index'") occurs because you define in your invoice tokenIndex=2, while its tokenIndex appears to be defined as 1 in the contract.

For non-fungibles, the allocation is defined using the following format: {tokenIndex}@{fraction}.

PS. We really need Contractum, writing and debugging in assembly is absolute PITA

Yes, definitely. I dusted off my "compilers dragon book" for this =)

[dr-orlovsky]

This is certainly not the place to discuss RGB21 schema etc, since it is 100% unrelated to AluVM specifications. I will wait for @EthanShang8989 to move it there and will continue discussion only after

[dr-orlovsky]

BTW this has to be an issue in http://github.com/RGB-WG/rgb-std/ and not here... @EthanShang8989 can you please move it there? (Just open there, close here and I will post my comment there once again)