-
Notifications
You must be signed in to change notification settings - Fork 3
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Worked on Addresses page under the Protocol
- Loading branch information
1 parent
4842335
commit c9002d2
Showing
1 changed file
with
152 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,152 @@ | ||
# Address | ||
|
||
### Overview | ||
|
||
Changes within the aelf blockchain occur through the execution of transactions. An **address** within aelf identifies a participant in a transaction, either as the sender or the recipient. The sender is denoted as **From**, while the recipient is denoted as **To**. | ||
|
||
**From** can represent: | ||
1. **User Address**: Identifies an individual participant. | ||
2. **Contract Address**: Identifies a smart contract. | ||
3. **Virtual Address**: Represents a virtual entity within the blockchain. | ||
|
||
**To** is exclusively a **Contract Address**, indicating that the transaction sender intends to execute a specific method within that smart contract. | ||
|
||
For further details on each type of address in the aelf blockchain, please see below. | ||
|
||
|
||
### User Address | ||
|
||
A **User Address** in aelf is generated from a unique key pair owned by a real user of the blockchain. Here’s how it works: | ||
|
||
##### Key Pair Generation: | ||
|
||
- A User Address is derived from a key pair using the `IAElfAsymmetricCipherKeyPair` interface. | ||
- This interface includes | ||
|
||
```base | ||
public interface IAElfAsymmetricCipherKeyPair | ||
{ | ||
byte[] PrivateKey { get; } | ||
byte[] PublicKey { get; } | ||
} | ||
``` | ||
|
||
Currently, aelf blockchain utilizes ECKeyPair for this purpose, similar to many other blockchain systems. | ||
|
||
##### Generating a Key Pair: | ||
- Users can use the [aelf-command](../reference/cli/introduction.md) tool to create a valid ECKeyPair: | ||
|
||
```shell | ||
aelf-command create | ||
``` | ||
|
||
- You will need to provide a valid password. The tool generates a `.json` file containing the public and private keys, encrypted with your password. | ||
|
||
##### Using dApp SDK: | ||
|
||
For dApp developers, the aelf JavaScript SDK [js-sdk](../reference/chain-sdk/javascript/js-sdk.md)` offers a method based on [bip39](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) for deterministic key pair generation: | ||
|
||
```javascript | ||
import Aelf from 'aelf-sdk'; | ||
Aelf.wallet.createNewWallet(); | ||
``` | ||
|
||
This method returns an object with the mnemonic, key pair, and address encoded in base58. | ||
|
||
##### Generating an Address | ||
|
||
When you create a new wallet using the `aelf-sdk`, it will return an object with three important parts: | ||
|
||
1. **Mnemonic**: A phrase used to generate the key pair. | ||
2. **Key Pair**: Contains the public and private keys. | ||
3. **Address**: The unique identifier for the wallet. | ||
|
||
In aelf, we usually encode the address in a format called base58. The address is derived from the public key by taking the first 30 bytes of its double SHA-256 hash. Here's how you can get the address from the public key using the aelf-sdk: | ||
|
||
```javascript | ||
import Aelf from 'aelf-sdk'; | ||
const address = aelf.wallet.getAddressFromPubKey(pubKey); | ||
``` | ||
|
||
|
||
##### Address Representation: | ||
|
||
- The User Address in aelf is represented using Protobuf message Address | ||
|
||
```protobuf | ||
option csharp_namespace = "AElf.Types"; | ||
message Address | ||
{ | ||
bytes value = 1; | ||
} | ||
``` | ||
|
||
In summary, a User Address in aleft blockchain is fundamental for identifying users and interacting with the blockchain securely and effectively. | ||
|
||
|
||
### Contract Address | ||
|
||
A **Contract Address** in aelf blockchain uniquely identifies a Smart Contract. Here’s how it’s created: | ||
|
||
##### 1. Calculation Method: | ||
- A Contract Address is determined during the deployment of a Smart Contract. | ||
- It’s calculated using a combination of the blockchain's **chain id** and a *serial number associated with the contract. | ||
|
||
##### 2. Implementation: | ||
|
||
Here’s how you can build a Contract Address in aelf: | ||
|
||
```c# | ||
private static Address BuildContractAddress(Hash chainId, long serialNumber) | ||
{ | ||
var hash = HashHelper.ConcatAndCompute(chainId, HashHelper.ComputeFrom(serialNumber)); | ||
return Address.FromBytes(hash.ToByteArray()); | ||
} | ||
public static Address BuildContractAddress(int chainId, long serialNumber) | ||
{ | ||
return BuildContractAddress(HashHelper.ComputeFrom(chainId), serialNumber); | ||
} | ||
``` | ||
|
||
- `HashHelper.ConcatAndCompute`: Combines the chain id and serial number hashes. | ||
- `Address.FromBytes`: Converts the resulting hash into a readable Address format. | ||
|
||
|
||
##### 3. Usage: | ||
- Developers deploying Smart Contracts on aelf blockchain use these methods to generate unique Contract Addresses dynamically. | ||
|
||
In essence, a Contract Address in aelf blockchain ensures each Smart Contract can be uniquely identified and interacted with securely across the network. | ||
|
||
|
||
### Contract Virtual Address | ||
|
||
In the aelf blockchain, every contract has the capability to create additional virtual addresses based on its main Address. These virtual addresses are known as **Virtual Addresses**. | ||
|
||
##### 1. Creation Process: | ||
|
||
- Virtual Addresses are generated by applying a hash function to the main Address of the contract. | ||
- This process allows contracts to create multiple unique identifiers dynamically. | ||
|
||
|
||
##### 2. Use Case: | ||
|
||
- For instance, in aelf blockchain, when transferring tokens using the MultiToken contract, both sender and recipient are identified by their respective Addresses. | ||
- Virtual Addresses extend this functionality by enabling the creation of unique identifiers for specific transactions or actions within a contract. | ||
|
||
|
||
##### 3. Creation Process: | ||
|
||
- Virtual Addresses are controlled exclusively by the primary contract. | ||
- This capability allows contracts to manage transactions and funds independently for each user, ensuring secure custody. | ||
|
||
|
||
##### 4. Utility: | ||
|
||
- Virtual Addresses serve as reliable identifiers generated through business actions on the contract. | ||
- They are particularly useful for token transfers and other interactions where unique identification is crucial. | ||
|
||
|
||
In summary, Virtual Addresses in aelf blockchain enhance the flexibility and security of contract interactions by providing unique identifiers derived from the main contract Address. | ||
|
||
|
||
|