Removing the ‘middle man’ — enabling full blockchain API access

paul arssov
4 min readAug 19, 2021
A way of enabling blockchain access for devices

1. The problem

So far Ethereum proved to be the most popular blockchain — this article focuses on Ethereum and Ethereum virtual machine / EVM based blockchains.

Unfortunately the access to Ethereum instances for decentralized app-s / Dapp-s has been ‘crippled’.

What do I mean by ‘crippled’?

To access the blockchain, no matter how many intermediate layers a Dapp goes through, it finally calls the Ethereum RPC API —

The function which actually writes on the blockchain is — eth_sendTransaction and its variation — eth_sendRawTransaction .

These 2 functions are responsible for:
- transfer of the native coin (ETH, BNB…) from one account to another
- deploying of smart contracts
- calling functions of smart contracts

As part of the infrastructure for Dapp developers blockchains provide URL-s for RPC API access like for ex.:
-<developer key> — Ethereum / Ropsten testnet
- — Binance smart chain / BSC testnet
- — polygon/matic testnet

The answer to the question — ‘What do I mean by ‘crippled’?’ is that the calls to eth_sendTransaction and eth_sendRawTransaction are disabled.

As a result of the restriction a Dapp developer can not directly do transfers, and/or deploy or call smart contracts.

And, as a result of of the restriction a layer of middle-men providers was created and keeps growing — Metamask and a lot of wallet providers.

To state the problem differently — most blockchain infrastructure providers allow read-only access to the blockchain.

To be able to write on the blockchain most Dapps have to call not only the blockchain infrastructure URL but also Metamask and/or wallet provider RPC API-s.

The ‘gatekeepers’ for posting transactions (writing) on the blockchain

2. One solution

Facing restrictions the question comes — ‘How do we bypass the restrictions and be able to make transfers, and deploy and call smart contracts?

An independent Dapp developer can run their own node of a blockchain and able to make transfers, and deploy and call smart contracts.

How exactly is this done?

The most popular software to run an Ethereum node is — geth . In addition to having the ordinary Ethereum APIs it has its own RPC APIs —

An independent Dapp developer can start a node of a specific Ethereum blockchain instance, like for ex. -

geth — datadir node-p1/ — rpc — rpcapi ‘personal,db,eth,net,web3,txpool,miner,admin,clique’ — networkid 137 — allow-insecure-unlock console

- networkid 137 — connects to polygon/matic mainnet
- networkid 56 — connects to BSC mainnet
- networkid 1 — connects to Ethereum mainnet

The important api added to the list of API-s is ‘personal’. When a node is started, normally it is not included in the list of ‘ — rpcapi’ .

3. Overview of ‘personal’ RPC API

The list of additional APIs is available on -

The important API-s on this list are -

It is these few APIs which allow bypassing the ‘middle-man’ layer of Metamask and all wallet providers.

A sequence of commands for a Dapp developer is -

- personal_newAccount — caller specifies a password and receives an address
There is no need of choosing a sequence of 12–24 words (Metamask,Binance wallet), and one or more passwords, or key files.

- personal_unlockAccount, personal_sendTransaction, personal_lockAccount — caller specifies a password to unlock and send transaction (transfer, or deploy/call contract), and then locks the account

4. Ultimate solution

Running a node is ‘heavy burden’ to carry for a Dapp developer.

Most of Dapp-s in the Ethereum and alike instances go ‘light’ having only a white-paper, web site and a smart contract.

The ultimate solution to the problem of ‘crippled’ RPC API access is for an infrastructure provider to enable this access.

The specific action to be taken is for the network administrator running the specific blockchain infrastructure to :
- modify the geth start script to include ‘personal’ namespace
- kill the geth daemon, and then start geth daemon

The downtime for the blockchain can be seconds to minutes.

Whether this proposal is going to be accepted or not remains to be seen.

The proposal may spark funding of countless grants analyzing the security of the proposal of enabling ‘personal’ namespace.

Most likely it is going to not an existing infrastructure provider but new ones which will be the pioneers in adopting of the proposal.

5. Benefits of the proposal

Removing the ‘middle man’ layer of Metamask and wallet providers and enabling full RPC API blockchain access are not the only benefits of the proposal.

Most of the current Dapp-s developers ‘live’ inside of a web browser.

This means that the Dapp needs a web browser, and/or node.js , and an operating system — whether desktop or mobile.

Allowing full RPC API access allows access to the blockchain for embedded devices which have neither a browser/node.js nor an operating system.

The number of embedded devices is much, much bigger than the number of desktop and mobile systems.

Read and write access for users and devices, with or without an operating system

Additional reading

Towards centralized blockchains
What a Dapp really is?
Decentralized web / dWeb — what is it?

Connect with me Linkedin



paul arssov

Creating the decentralized web —, building a decentralized communication platform