While my presentation was mostly talking about the state for web3.js itself, I would like to focus more on how Status uses web3.js and question the reason for doing so.
First let’s illustrate the current state of web3.js within Status app:
The proper interface between Dapp code and browser injected code is the web3 provider. Dapp must use their own web3.js library, to avoid incompatibilities between the version they are developped for and the one that would be otherwise injected by browsers.
In Status we only inject web3.js if the dapp doesn’t have it, so it was ignored in this schema.
You can see that the web3 provider communicates directly with status-go through the rpc url on localhost. Our web3.js provider is 100 lines of Javascript that implement the same methods available in the HttpProvider of web3.js 0.20, which should still be compatible with version 1.0 of the library. The HttpProvider is however marked as deprecated in the latter version.
Within status react the web3 object that is used everywhere is actually a simple javascript object that has a sendAsync method, which uses status-go call-web3
method.
There is one exception where call-web3-private
is used instead and doesn’t go through web3 but prepares and sends the json-rpc payload directly.
Finally Status API is a completely different thing that uses the webview bridge to communicate with status-react. It is used to offer functionnalities that are not part of web3.js such as providing the whisper address of the user, and ask permission to the user before letting dapps access these functionalities.
So as I tried to explain in my talk and everyone hopefully understood, there is actually 2 potentially different web3.js used in Status.
- one that only interacts with status-go through our web3 provider via http calls to localhost. We can keep it that way because new dapps should use their own web3.js.
- one that is used as a library by status-react. This discussion is about replacing it.
Various use cases for web3.js in status
- transactions: very simple call
- wallet related calls: erc20 and erc721 management are actually interactions with contracts
- interactions with contracts: simple rpc calls, we need to either start using web3.js eth-abi package or implement a proper version of the abi-spec to support dynamic types if we want to be able to interact with all contracts. So far we only had to deal with static parameters. Reads are eth_call, interactions are eth_send_transaction
- whisper: complex calls, web3.js does some heavy lifting abstracting the lack of bidirectional communication in json-rpc by polling regularly for new messages for each filter
- misc: current block, networkid; simple calls
Arguments
Data oriented: synergie with extensions and status-api
Testability
Simple
Less indirections
Better comprehension of Ethereum interface
Things that we still need to clarify
- test if our current web3 provider works with dapps that make uses of promises in web3.js 1.0.
- establish a bidirectionnal communication channel between react and go (bindings + signals ?)
- how this fit with the old and new transaction flow @andrey
Proposal
- progressively remove the use of web3.js in status-react to favor direct calls to status-go
- design a data-oriented way of declaring abi spec and implement it
Contract ABI Specification — Solidity 0.8.24 documentation
- implement json-rpc and json-rpc pub-sub in status-react
JSON RPC · ethereum/wiki Wiki · GitHub
RPC PUB SUB · ethereum/go-ethereum Wiki · GitHub
The first step is to decide if it is worth it (I think it is)
The second one is to agree on a draft of the data-oriented abi declaration and json-rpc usage
Then we can start gradually implementing.
Let’s discuss!