A Companion Guide to “First impressions with ERC 725 and ERC 735 - identity and claims” (Part 2)
5. Detail Flow of the Demo: walking through main.js
The code prepared by Julio’s demo comes with a good implementation of everything, and the flow is kept inside the code main.js. It is broken down into eight steps in his article.
As the main.js is executed once the command npm start is issued, we only see the console log output on the screen, but no detail about the data inside the deployed contract. Therefore I use the Go Ethereum client (geth) to access the Ethereum simulator and inspect the aftermaths.
Using geth to access deployed contract requires ABI (application binary interface) and the contract ID of the deployed contracts. Though I can follow the demo code to obtain the ABI on ClaimHolder.sol, I instead get the compiled ABI fro the online Remix tool. The variable abi in below screenshots contains the ABI from Remix.
Here is the ganache-cli Ethereum simulator with the 10 accounts.
After the main.js demo code is executed (npm start), we see four contracts being deployed on the Ethereum simulator. For sake of easy reference, here is a summary of them. We will see these contract addresses later in the step-by-step elaboration.
Step 0: Before demo is executed
The Ethereum simulator ganache-cli comes with 10 ethereum accounts. According to the main.js, the accounts are assigned as follows.
Note that only Fractal ID and Investor have the ClaimHolder contract.
Step 1: Fractal ID deploys its own identity contract
The Fractal ID’s identity contract is the ClaimHolder.sol deployed in the Ethereum network from the Fractal ID’s management account. Here is the code in main.js.
Note: jsonClaimHolder keeps the compiled bytecode and ABI from ClaimHolder.sol. Also the deployment is from management account of Fractal ID (i.e. accounts[0]).
According to the constructor in KeyHolder.sol, the first key is setup. The key is computed from the keccak256(address).
We first get the key by using getKeysByPurpose() with purpose set 1, which is the Management Key. We also use getKey(key) to obtain more detail about the struct Keys defined in ERC-725. Here we have the key of purpose 1 (Management) and key type 1 (ECSDA), and the key value.
We cross-check the key value corresponding to accounts[0].
Step 2: Fractal ID adds a Claim Key to its identity contract
Since accounts[0] is the Management Key, it can be used to add a Claim Key on this Fractal ID ClaimHolder contract. The process is done through addKey() with this code in main.js.
We can see how to compute the key, that is, keccak (hash) of Fractal ID Claim Account, which is accounts[1] in this demo. The purpose is set to CLAIM, that is, 3 as defined in ERC-725. Per design in KeyHolder.sol, only the address whose key is already in ClaimHolder contract with purpose 1 (Management) can perform addKey() function.
Again we get the key using getKeysByPurpose() and getKey(), we will see this Claim Key.
As we can see, the struct is the same as previous Management Key. Also we cross-check the key is associated to accounts[1].
Step 3: Investor deploys its (their) identity contract
Investor deploys its own identity contract. This is similar to Step 1. This contract is the same ClaimHolder.sol, but deployed by Investor management account. Here is the code in main.js.
After deployment, as expected, from the deployed contract we can get the key by getKeysByPurpose() with purpose 1. We can also see the Management Key detail by getKey().
And the key is hash of accounts[3].
Step 4: After Investor successfully undergoes KYC, Fractal ID signs a KYC claim for Investor
As Investor wishes to participate in the crowdsale of Very Good Company’s Token, he first needs to obtain the KYC Claim signed by Fractal ID.
After the required procedure is complete (off-chain), Fractal ID will create a claim, sign it, and pass it to Investor. Here is the code in main.js how the signature is generated.
According to the code, here are the steps,
- Create some meaningful data (hexedData). The actual data may be cross-checked during verification, or only the signature of any given data is checked.
- Create the data-to-be-signed (hashedDataToSign). It is the hash of a combination of Investor’s ClaimHolder Contract address, the claim type (KYC, 7) and hexedData. This combination is not fixed, but the verification steps (see in Step 8) needs to follow the same scheme to construct this data-to-be-signed. Note that it is the Investor ClaimHolder contract, not the Investor’s own account, to be included in this signed claim. Investor is using Investor ClaimHolder contract as proxy in this crowdsale.
- Generate the signature. Note that the signer is Fractal ID Claim Account, which is accounts[1] in our demo. Remember: this accounts[1] is already recorded in Fractal ID ClaimHolder contract as purpose CLAIM (Step 2).
In the final part we will finish our step-by-step walk-through on main.js.
