p10 auth

[aristidesstaffieri]

Migrates auth usage to p10, updates sdk version.

Notes -
This relies on this PR to be able to sign arbitrary blobs with Freighter - stellar/freighter#912
Also relies on this PR to be able to pass signed auth entries through assembly - stellar/js-soroban-client#114 (I have an assembleTransaction fn locally that we can throw away when that ships)
We use this external lib to abstract over wallet integration, so we need this to land as well before this will work.
Creit-Tech/Stellar-Wallets-Kit#1

This allows multi-party auth to create and execute a swap, optionally using invoker auth as one of the auth entries. If the user who acts as the exchange is also one of the swappers, their signing process will be skipped and the same signature that the tx uses will be used for contract auth.

[aristidesstaffieri]

@dmkozh sorry I accidentally resolved our last convo 😄

So when I look at the interface for SorobanCredentials, I don't see any nonce on it.
https://github.com/stellar/js-stellar-base/blob/soroban/types/next.d.ts#L11246

I believe this is the right object, looking at the authorization entry here
https://github.com/stellar/js-stellar-base/blob/soroban/types/next.d.ts#L6667

Maybe we're missing this in the sdk? @Shaptic any tips on this one?

[dmkozh]

So when I look at the interface for SorobanCredentials, I don't see any nonce on it.

That's because nonce is a part of address credentials only (another variant for credentials is source account, which doesn't need nonce). IIUC in the SDK that corresponds to value().nonce() when value() is non-void.

[aristidesstaffieri]

So when I look at the interface for SorobanCredentials, I don't see any nonce on it.

That's because nonce is a part of address credentials only (another variant for credentials is source account, which doesn't need nonce). IIUC in the SDK that corresponds to value().nonce() when value() is non-void.

ah got it, thank you!

[aristidesstaffieri]

@dmkozh as far signing the appropriate auth entry goes, I have a few questions -

I have a tx for an atomic swap which does the following require auth calls
https://github.com/stellar/soroban-examples/blob/main/atomic_swap/src/lib.rs#L39

Once the tx is built, I end up with 2 auth entries. Should each one of those be signed by both swappers in this case or is there a specific entry that should be signed by each? I sort of expected to be able to match addresses from the entry to a specific signer in order to sign the appropriate one, by doing something like this -

for (const entry of authEntries) {
      if (entry.credentials().switch().name === "sorobanCredentialsAddress") {
        const entryAddress = entry.credentials().address().address().accountId()
        const entryNonce = entry.credentials().address().nonce();

        if (
          signerKeypair.xdrPublicKey().toXDR("hex") ===
          entryAddress.toXDR("hex")
        ) { .... ....  }
     }
   }

Only one entry is a sorobanCredentialsAddress so I think I misunderstand who needs to sign which entry.

[dmkozh]

Only one entry is a sorobanCredentialsAddress so I think I misunderstand who needs to sign which entry.

Maybe it's because another one is invoker? The address in credentials must sign the respective payload. If credentials belong to a source account , you just need to attach the respective auth entry to transaction (so that source account will sign it as a part of transaction)

[aristidesstaffieri]

Only one entry is a sorobanCredentialsAddress so I think I misunderstand who needs to sign which entry.

Maybe it's because another one is invoker? The address in credentials must sign the respective payload. If credentials belong to a source account , you just need to attach the respective auth entry to transaction (so that source account will sign it as a part of transaction)

ah got it, yup that makes sense. The first swapper is the invoker in this case. Thanks again!

[Shaptic]

gotta love seeing those deleted files amirite 😎

[aristidesstaffieri]

@dmkozh do you know what the correct value would be for building a key for a LedgerKeyContractData? I have the following but it seems I'm missing something.

 const key = xdr.LedgerKey.contractData(
            new xdr.LedgerKeyContractData({
              contract: xdr.ScAddress.scAddressTypeContract(
                Buffer.from(contractID),
              ),
              key: xdr.ScVal.scvLedgerKeyContractInstance(),
              durability: xdr.ContractDataDurability.persistent(),
              bodyType: xdr.ContractEntryBodyType.dataEntry(),
            }),
          );

server.getLedgerEntries([key]).then((response) => {
            if (response.entries.length) {
              const parsed = xdr.LedgerEntryData.fromXDR(
                response.entries[0].xdr,
                "base64",
              );
              expirationLedgerSeq = parsed.contractData().expirationLedgerSeq();
            }
          });

when trying to get that key I end up in this xdr error -

XDR Write Error: got 56 bytes, expected 32
TypeError: XDR Write Error: got 56 bytes, expected 32

[aristidesstaffieri]

@dmkozh do you know what the correct value would be for building a key for a LedgerKeyContractData? I have the following but it seems I'm missing something.

 const key = xdr.LedgerKey.contractData(
            new xdr.LedgerKeyContractData({
              contract: xdr.ScAddress.scAddressTypeContract(
                Buffer.from(contractID),
              ),
              key: xdr.ScVal.scvLedgerKeyContractInstance(),
              durability: xdr.ContractDataDurability.persistent(),
              bodyType: xdr.ContractEntryBodyType.dataEntry(),
            }),
          );

server.getLedgerEntries([key]).then((response) => {
            if (response.entries.length) {
              const parsed = xdr.LedgerEntryData.fromXDR(
                response.entries[0].xdr,
                "base64",
              );
              expirationLedgerSeq = parsed.contractData().expirationLedgerSeq();
            }
          });

when trying to get that key I end up in this xdr error -

XDR Write Error: got 56 bytes, expected 32
TypeError: XDR Write Error: got 56 bytes, expected 32

Shaun pointed out the empty contract instance for key but not sure what that should actually be.

[Shaptic]

@aristidesstaffieri this is before the getLedgerEntries call, right?

Is the contractId correct built correctly? I can't spot how it's defined initially. It might be more reliable to do something like new Contract(contractId).address().toScAddress()?

[aristidesstaffieri]

@aristidesstaffieri this is before the getLedgerEntries call, right?

Is the contractId correct built correctly? I can't spot how it's defined initially. It might be more reliable to do something like new Contract(contractId).address().toScAddress()?

yup that was totally it, thanks @Shaptic you wizard 🧙

[Shaptic]

🏎️

[Shaptic]

nyyyyyyyeaow 🏎️

[Shaptic]

hell:clap:yeah:clap: