#Replace BytesN<32> with Address 💡

58 messages · Page 1 of 1 (latest)

neat vigil
#

Contract IDs are represented as BytesN<32> throughout the SDK.

As part of Auth Next we have this Address type, and idea is to support future account abstraction that everything is one of these addresses and most code shouldn't need to think about the type of address something is.

If we end up succeeding at true account abstraction, in the end an Address that is a contract ID should be usable anywhere any Address is usable and the importance of contract vs account addresses should fade away even more.

In the SDK we use BytesN<32> for contract IDs and pass them around as their raw bytes. This is visible to the developer in a few places:
● Contract clients must be instantiated with a BytesN<32>.
● Registering contracts in tests returns a BytesN<32>.
● Passing around contract IDs between contracts in our examples use BytesN<32>.
● Env call stacks use BytesN<32> as the contract ID parameter.

However, by proliferating this BytesN<32> about in so many ways, the developer has to learn about and deal with both Address and BytesN<32> and their conversion. When coding myself I find myself doing conversions between them as a matter of necessity and their distinction isn't adding much value to the code I write – it feels like busy work.

#

💡 Let's start using Address everywhere where we use contract IDs.

#

❓ Why:

#

● To the point that others have made many times, developers shouldn't need to distinguish between contract IDs and account IDs, so it seems odd we're leading with BytesN<32> in so many places.

#

● It'd clean up the testing API. register_contract would return an Address, that could immediately be used as an Address to be authorized.

#

🤔 Why not:

#

● We'd be introducing new failure cases into some code paths. e.g. Invoking an Address instead of a BytesN<32> could fail if the Address was an account. However, this seems like minimal impact given the same code path can fail if the contract doesn't exist.

#

● ?

#

Thoughts @stiff cosmos @candid sigil @surreal idol ?

stiff cosmos
#

(the conversion is already there as it was a faster/more flexible solution)

neat vigil
#

Yup, that's it. I'll repost the above there.

stiff cosmos
#

in general this sounds good to me. address in call stack might be a little confusing or the invocation case you've mentioned... but probably consistency is worth it - I was never a fan of specifying <32> explicitly - that feels a bit arbitrary

neat vigil
#

I think we can expand the issue above to contract ID is Address, always.

#

I think <32> was fine, it felt natural, but now that Address is required for auth, it feels O.o to be frequently converting back and forth.

#

And everything being Address will make more sense in the long run for account abstraction.

#

@stiff cosmos Hope you don't mind I updated the issue title to reflect using Address everywhere, not limited to deploy/invoke.

stiff cosmos
#

yeah, that's good, thanks

split crater
#

I like the plan

indigo lake
split crater
#

basically the sdk does not require a 32 byte length array, it just requires a Bytes; so then if that gets passed to the env, you could use this method: #1105417525572948018 message to still convert it to a u256, by padding it with zeros; however that still doesn't handle the issue that someone could pass an array with more than 32 bytes...

neat vigil
#

That function is a host function so it only knows about Bytes.

#

The SDK function that wraps the host function uses BytesN<32>.

split crater
#

not sure how i missed that. maybe i had been looking at an old commit

neat vigil
#

Coming back to plus1 this again because somehow twice in one day I got tripped up by this again 😅.

neat vigil
#

As part of removing BytesN<32> for contract ID's, I now have this interesting thing that I have items all through the SDK called contract_id with a type Address.

Do folks feel like "contract id" is the right terminology and vocabulary still?

I'm thinking of switching to contract_address, but it's also quite long. In some places I can simply use contract, but then in others that is somewhat ambiguous.

#

Given we have Account IDs and Contract IDs, maybe we should have made Address called Id 🤔

surreal idol
#

Id is probably a bit too generic

surreal idol
# neat vigil As part of removing `BytesN<32>` for contract ID's, I now have this interesting ...

In some places I can simply use contract, but then in others that is somewhat ambiguous.
contract does seems the most straightforward to me. can you give an example of where this is ambiguous? is it where we have both a contract address and a contract client? If that's the case I feel like a naked contract being an address and a client is fully qualified contract_client is an acceptable convention

runic wren
#

What I find interesting is that even when address is supposed to be opaque, we are still naming variables to denote whether they are a contract or an account 🙂
I don't think you would be a fan of using identity: Address ? it probably does sound a bit off in some contexts @neat vigil

stiff cosmos
#

Address seemed to me be a more broadly used term. as for opaqueness, conceptually everything is a contract actually

neat vigil
#

I agree, everything is a contract, "Accounts" just happen to have no callable functions, today, maybe tomorrow they will!

#

Well, I'm wrong actually, Accounts have a __check_auth function in practice.

#

I'll replace contract_id with contract everywhere I can find.

neat vigil
split crater
#

the name of the paremeters doesn't need to be the same for two of the same type i don't understand the point there but maybe i misunderstood the msg

neat vigil
runic wren
lilac nova
#

How many different ID are there ?

#

And which are relevant ?

split crater
#

the names are just... names of data that are using the same type, in this case we're discussing address.

neat vigil
#

The SDK released today uses Address in most places now.

split crater
#

what is the shape of Address

#

looks like it's exactly the same as what bytesn32 was but just checking

stiff cosmos
#

it's a union between 32-byte contract id and AccountId

fresh wagon
#

Hello, now with this implementation the Address in this code
let contractB = dcontracb::Client::new(e, &contractb_id);
is the same contract id or the contract_address that is possible to get with env.current_contract_address() ?

stiff cosmos
#

yeah, there is no distinction now - just use address everywhere

split crater
#

I mean... can I see an example of an Address object because I can't seem to figure it out, I thought it was like {object{address{32byte id}}}

stiff cosmos
#

not sure if you mean something else though...

errant mortar
errant mortar
# split crater I mean... can I see an example of an Address object because I can't seem to figu...

@split crater Yeah, do you mean in xdr? or in text? or in a rust contract?
If you mean in text, a contract address would look like CA3D5KRYM6CB7OWQ6TWYRR3Z4T7GNZLKERYNZGGA5SOAOPIFY6YQGAXE, note it starts with C., whereas stellar accounts start with G (or M for muxed accounts).

For xdr, see @stiff cosmos 's link above.

For in rust, I'd expect it is something like: Address::Contract(hash: BytesN<32>) (but haven't checked)

stiff cosmos
#

in rust address is a host object that resolves either to a contract or to a classic account

split crater