Simplify blockchain on-boarding to help persons-in-need

Photo by Siddhant Soni on Unsplash

The ambition: share data among all humanitarian organisations

It is well known that with its data Uber knows more than the municipality of San Francisco about its citizens’ mobility, and therefore is more powerful when organising traffic. The same holds for Google facing the Canadian government on the urbanisation plan of Toronto. Municipalities, governments and international organisations hold their data in silos and have a limited view of the whole. This makes them weaker and less efficient than the GAFA.

The ambition of project Machu Picchu is to bring an open-source set of tools and data that allows NGOs, governments and international humanitarian institutions become performant in their mission to help the persons-in-need. Sharing this data, they would be able to better plan, build programs and satisfy their “customers”. This data has to be maintained and expanded, avoiding any central authority controlling the data.

Project Machu Picchu uses the decentralised property of the blockchain to let each person-in-need keep ownership of their personal data. Every organisation that accesses the data would pay the owner a micro-fee (0.05 cents for example). Using the Ethereum ecosystem, all the pieces of the technical stack are available and ready to be assembled. Describing them will be the subject of another article. We’ll focus today on one specific point.

Prior art note: The WFP pioneered in this domain in 2017: https://www.wfp.org/news/blockchain-against-hunger-harnessing-technology-support-syrian-refugees. But this use case takes more advantage of the notarial properties of the blockchain, and the resulting data is centralised at the WFP.

Note: the International Red Cross is considering DLT for the purpose of sharing data: https://www.rodekors.dk/sites/rodekors.dk/files/2020-11/The Next Generation Humanitarian Distributed Platform %281%29.pdf. This study paper is focused on DLT and doesn’t consider IPFS. Maybe we can do something together.

The problem: simplify access to blockchain

How we can bring the blockchain within reach of a person-in-need (a refugee, a smallholder farmer, an agro-breeder etc.) when at best this person has an old-style feature phone and can barely read?

To illustrate this issue, and the challenge, here it how blockchain on-boarding is done on Ethereum, today:

• The user creates an account on the main net. This is free of charge.
• The user can receive crypto in this account, from someone or by buying on a public exchange. There is a transaction fee, paid by the person who transfers the crypto.
• If the user needs to create a wallet to store service tokens and not only store pure crypto, there is a transaction fee to pay. Hence the previous step is pre-requisite. So there are 2 distinct steps to on-board someone on blockchain.

Using Metamask (see below) on a browser, or Metamask Mobile on a smartphone, it is possible to create a wallet for free, but this wallet not a smart contract: it is a storage in computer local memory. In addition, to further interact with this wallet you need at least a smartphone, and even to use Metamask itself you still need some blockchain literacy. The challenge seems insoluble, knowing the complexity of blockchain on-boarding and the degree of computer literacy of the average person-in-need.

A solution exists. The general problem can be decomposed into 2 facets:

• identity: in a digital world, identity is proven by a name and a password. In the physical world, identity is proven by an ID card or a passport.
• ownership of goods: in a blockchain world, ownership is proven by a pair of private and public keys. In the physical world, ownership is proven by a material fact and by social consensus.

The rest of the article will continuously juggle with these 2 facets.

The solution, in short

Knowing that the problem of bringing blockchain to a person-in-need is a subset of the general problem of blockchain usage, the solution that Machu Picchu is exploring is the following:

• Let the helper interface to the blockchain for a person-in-need be the humanitarian institution. Using a meta-transaction (using Gas Station, Biconomy or other), this institution can pay the creation fee of the wallet on behalf of the person-in-need so there is no preliminary need of crypto for someone to on-board;
• once the blockchain on-boarding is established, the persons-in-need would be the owner of their wallet and this wallet is actually a virtual secretary keeping the secret keys and executing the logic of the humanitarian process (it’s an instance of a smart contract);
• in routine, the virtual secretary would need some crypto funds to pay the subsequent transaction fees. These funds may come from the support institution, or levied from the (small) service fee that the person-in-need would pay for some compelling community service;
• the persons-in-need would have a set of predefined commands to this virtual secretary;
• each command would be a SMS or USSD message protected by OTP (One Time Password);
• one of the commands, with the associated OTP, would be the authentication. The rest of commands are for exercising the ownership of the wallet.

We will describe this topic in a future article, once we have implemented a prototype to prove its feasibility. Today we’ll explore the core of the blockchain on-boarding and usage: the difference between how geth, ganache and Metamask generate their key pairs.

You need not read this second part if you are only interested in the final objective. Like the Internet, you don’t need to know how your IP address is generated to use a social network. But if we want to simplify blockchain access to the persons-in-need, we need to understand in detail how account addresses are generated and how this operation works.

Blockchain access 101

At the first days of Ethereum, the only way to access the blockchain is to run a client node of the blockchain network. The most popular example of a client node software in Ethereum is geth, as below: an application program sends transaction requests to a node, that broadcasts it on the blockchain.

To speed up development and tests, ganache was introduced that simulates in computer memory the behaviour of a complete blockchain network. It is also possible to to make persistent the state of a test by writing the state of the simulated blockchain to storage.

To simplify further blockchain access for test and also for real transactions, Metamask is a browser plug-in that allows any application to access the blockchain without running a node or even know which node to connect to. Metamask takes care of finding a blockchain node on the Internet, that will execute its blockchain transaction commands.

The challenge: different words, same concepts

However, when designing and programming an easy-to-use application using these 3 tools (geth, ganache or Metamask) you are faced with a discrepancy of wording when it comes to account management.

In the following table, guess what are the meanings behind the terms “password”, “passphrase”, “mnemonic”, “seed phrase”, “HD path”? which ones are similar and which ones cover different meanings? Quite puzzling. When does an end-user need to know these concepts? Do they need to know them after all?

How can we make this blockchain wordings simpler to understand, and to use? After all, the challenge boils down to preserve identity and ownership of accounts.

How the blockchain key pairs are managed

Let’s align the actual meaning of the terms

The blockchain uses “public-key cryptography” to protect the accounts that own and store crypto-currencies and tokens, see more here https://en.wikipedia.org/wiki/Public-key_cryptography

Let’s see the solution before the explanation. Here is how the different terms above match each other.

The explanation: how the key pairs are generated

Understanding how the key pairs are generated by each of these 3 tools will help us understand the concepts (identity and ownership) that are common to the tools and named using different words. In the following diagram the names in italics are the (mostly) cryptographic algorithms used to derive an element from its source.

With geth:

• The user has no identity.
• At creation of the account, its private key is generated by a cryptographic function that uses as seed the “password” provided by the user . No randomness.
• When the user “unlocks” the account to do a transaction, the “passphrase” is asked and used as seed to generate again the private key and validate it against the value stored for this account. This proves the ownership of the account, authorising a transaction using this account.

With ganache:

• The developer (the user) has no identity.
• A pseudo random set of 12 words is generated that is used as seed (“mnemonic”)
• The seed, plus 10 different “HD paths” (aka “HD derivatives”), are used to generate 10 private keys associated with 10 accounts.
• The keys are used in blockchain API primitives without further checking since this is for tests and the ETH crypto has no value here.
• As ganache is a locally simulated blockchain network, all keys and accounts disappear when ganache shuts down, unless persisted to storage. No special protection is required.

With Metamask:

• When you create a Metamask wallet, the identity of the wallet owner is set (username, password).
• A random set of 12 words is generated, that is used as seed (“seed phrase”)
• The seed, plus a “HD derivative”, are used to generate a different private key each time a new account is created.
• Each time a Metamask wallet is open, the identity of the wallet owner is controlled (username, password). From there and for this session, it is assumed that an approval dialog is enough to secure each transaction.
• When the user changes computer or browser, the “seed phrase” plus each “HD derivative” are enough to regenerate the accounts of the same wallet on this computer or browser. The “HD derivative” is “deterministic” and is independent of the computer and the browser.
• From this logic, it is clear that what Metamask calls “account” is simply a key pair private-public, not an account like a bank account. If you use this “account” in 2 different blockchain networks, for example the main net and Rinkeby testnet, you must consider that you are dealing with 2 distinct accounts. Else, you may mix up your ETH. It is as if Metamask is a portal that gives you access to an account at Citibank and an account at Paribas that happen to have both the same number (!!).

From this understanding, we can now design and implement the simple blockchain on-boarding and usage process that was described above. Stay tuned.

Notes

• The “HD derivative” is a simple algorithm to generate a string that is appended to the seed phrase to create the private key. More explanation about the “HD derivative” here: https://medium.com/myetherwallet/hd-wallets-and-derivation-paths-explained-865a643c7bf2. The author is the creator of MEW, My Ether Wallet, which has the same approach as Metamask to create accounts.
• “Keccak256” is a hash algorithm used by Ethereum: https://ethereum.stackexchange.com/questions/11572/how-does-the-keccak256-hash-function-work
• ECDSA is a cryptographic algorithm used by Ethereum to generate a public key from a private key: https://hackernoon.com/a-closer-look-at-ethereum-signatures-5784c14abecc
• BIP39 is a set of cryptographic algorithms (Bitcoin Improvement Proposal 39) to generate a random sequence of 12 words and from this random sequence to generate a private key. See https://medium.com/coinmonks/mnemonic-generation-bip39-simply-explained-e9ac18db9477