Address
In Orbs, addresses are represented in hex values, and is the 20 least significant bytes of the Sha256 digest of the public key.
For example, the below is a valid address:
Addresses or 'accounts' do not need to be created - the address is a simplified representation of the public key which is derived off the private key used to operate with the blockchain
The Orbs Contract SDK offers an API for working with address, in order to use it you need to import the address as such:
Checksum
Addresses are case sensitive, similarly to ethereum, the checksum is calculated according to the address in its case sensitive format and thus it is always recommended to use the address in that way. since everything is hex encoded, the underlying data does not change between the case status, meaning that an all lower-case, all upper-case and case-specific address of same letters, represent the same account, however the checksum can only be calculated correctly if the case sensitivity version of the address is presented
Having the ability to validate the checksum helps us make sure that in cases where human errors (typos) are made when inputting an address, we can alert and possibly reject the transaction (depending on the selected logic)
The transaction will be accepted when the addresses are uniform, meaning all-lower or all-upper case. Of course, the transaction is also accepted when the mixed-case checksum-ed address is valid.
Signer and caller
In Orbs there are two terms around well-known address during runtime, which are the Signer address and the Caller address.
The Signer address is the address of the account which is signing the transaction, in an ERC20 scenario for example, we will use that account to sign the transaction and transfer funds to/from it, depending on the operation.
The Caller address is the address of the entity that called the current function - while it may be the same as the signer address for simple scenarios, it can also be different, for example in the case where the contract calls a different contract
In the image above, the User calls contract one, at this stage:
Signer: User
Caller: User
Next, the logic of Contract1 will call Contract2, and at this stage when executing Contract2:
Signer: User
Caller: Contract1
Address API
There is no Address native type, and addresses are referred to as []byte
internally in the code. This is why it is important to perform data validation to ensure that indeed the data in the []byte
matches a valid address format.
ValidateAddress
The API call ValidateAddress
exists for that and can be used as such:
As part of a code:
If the validation fails, the execution will return an error, so there is no return value from this validation function
GetSignerAddress
In any function, calling GetSignerAddress
will return the []byte
representation of the signer address
GetCallerAddress
In any function, calling GetCallerAddress
will return the []byte
representation of the caller address
GetOwnAddress
In any function, calling GetOwnAddress
will return the []byte
representation of the currently executing contract address
GetContractAddress
In any function, calling GetContractAddress
will return the []byte
representation of the a specific contract address as specified in the argument
Last updated