JSON RPC Spec & Testing Community Call Nov 27th

JSON RPC Spec & Testing Community Call Nov 27th ======================= 8am PST, Nov 27th Agenda: https://github.com/spadebuilders/community/issues/15 Zoom Video: https://zoom.us/j/946476323 EthMagicians Discussion / Follow up Notes: https://ethereum-magicians.org/t/json-rpc-specifications-and-testing-community-call-nov-27th-2018/2031 ## Action Items Everyone review the PR of the spec * https://github.com/ethereum/EIPs/pull/1474 * Chris L volunteered to be a maintainer * let's push for Last Call so this can get nailed down Boris to setup separate repo, it may be easier to collaborate there than just in a single PR thread * https://github.com/spadebuilders/ethereum-json-rpc-spec Should there be a separate process for proposing JSON-RPC extensions? * breaking changes and/or major additions to the spec should likely be filed as EIPs * for convenience, working group have a separate repo * need to start working and see how it evolves Stakeholders include: * client devs, those looking to build a new, compatible client * middleware -- web3js, ethers.js --> definitely need * devops / people looking to run many nodes * miners Middleware Flags for Debug * many dapp developers don't know that JSON-RPC exists -- blame middleware for errors * talk to middleware about a debug flag or common approach to get at underlying responses Testing * INFURA has released compatibility / interop testing https://github.com/INFURA/rpc_sanity_test * Bob pointed to Casey's tests here http://cdetr.io/eth-compat-table/ -- which is an RPC test suite https://github.com/cdetrio/interfaces/tree/0fcb796440dea702e308710457346d29b051f365/rpc-specs-tests -- part of Hive https://github.com/ethereum/hive * INFURA can be involved * Dave said he'd be interested in testing * loop back with Piper EEA * Boris to coordinate with Ron / Chaals / Alex at EEA * Loop in Ben Burns as EEA technical lead? * How will EEA contribute? * Likely next step is an internal EEA call with interested members & clients - Block Apps, Quorum, Clearmatics, Pegasys, etc. ## Notes Introductions Boris Mann Bob Summerwill EG Galano - Consensys, Infura * feel this pain * digressions between clients * open sourced Ryan * Infura * getting multiple clients agreeing on responses * generally spots where we can clean up responses Chris Leishman * Core Engineering Consensys * core ETH protocols that we can do to move things forward * technical product manager -- APIs and specs consistent Dave Appleton * use GO a lot * using Parity and Geth, different backends * replacement for EthClient because of differences Charles * Polymath work on open source dev & community * adding value Antoine * core engineering consensys * working on a client Elixir / Erlang -- right JSON RPC Paul Cowgill * working on Tasit Labs https://tasit.io * building an SDK for making standalone mobile dapps * JSON-RPC batching signed messages for Alex * consensys * working with EEA on organizing task forces * educating EEA members on how to get involved === What are clients doing now in attempting to build compatible specs? Intersection between Geth / Parity, then try and do what's next and attempt to pick between the two Repo for JSON-RPC spec, tests - doesn't need to be in one repo, but does need to be run independently This is part of broader spec process, Boris has PR against EIPs repo to highlight these sub-specs, would like to list maintainers for each of them Do people know who maintainers are for other specs? * devp2p * Felix Lange changed the wiki page last time Whisper --- EEA interest * Compliance process * Solid spec to build on * Point Proposal for upgrades to spec * as EIPs, or? Doesn't lead to hard forks? - shouldn't be too rapid an iteration - which clients support it will dictate what how much usage - web3js, ethjs, metamask, custom dapps The spec was Ethereum wiki pages, when Parity left, they made their own pages * No coordination mechanism done * Fork and another clients Current spec, large amount of undefined behaviour Start of EEA -- efforts which Dan Finlay and Casey Detrio and others had done at a hackathon in Seattle * trying to build tests * some of the push back from Parity * overspecification was a problem * overspecified -- that's bad as well Stakeholders as mentioned above about spec changes * large scale * mining, not a lot of ambiguity * came out during testing -- JSON-RPC is stateful, get different answers -- challenge to test Testing? * any tests * hive test repo --> Peter Sz, can we use those tests * what does interop mean? * not just tests -- its running across different clients * compliance vs other clients * sync up to a certain level, should see same blocks * http://cdetr.io/eth-compat-table/ * add a column -- stability -- likelihood of breaking changes Can have things rolled out whenever Middleware - very often when breaking changes or errors - developers only understand middleware -- not what JSON-RPC is - in the future, if we can think of ways we can work with middleware providers to better expose underlying RPCs that are having an issue - large number of dapp developers don't really know about this - maybe debug flag? best practice -- documenting what the call underneath is Infura, testing - working on hiring - can be involved, can't take it all on EEA Working Group * not sure when to happen * Ben Burns spec? * Ping Ron Resnick -- cc people who expressed interest Clients that will be compatible * list? * quorum * block apps * clearmatics * pantheon Ben Burns Ganache CLI * supporting all devs * doing testing on their laptops * dapps are going to get right results on mainnet * can run in two flavours -- geth or parity * Ben was harsh on how bad it is * middleware perspective Ganache until recently encoded numbers incorrectly Dave - test suite willing to work on EEA could help in creating test suites, modular pieces Developer evangelism -- if test suite looks like the hive test suite Client developers will want to be on the list Lots more develop than we have in a long time Post Shanghai, clients died -- now with ETH2, more client dev than ever Hinting at JR-IP process * two concerns * one issue -- non breaking changes can go through * breaking change needs to go through EIP * discoverability of separate process * might get separate issues Want to get to canonical specification for all of these things -- the Ethereum platform EIPs are the way of making changes to that EIPs are the working notes -- I have to read all of these??? Imagined that we'd end up with a single, broader paper EIPs are working through changes PRs against the original paper Could be a single thing Is that over constraining? Maybe tieing them all together isn't great -- for Whisper and Swarm as an example Somewhat concur with that -- single specification for each piece of the protocol, whether single doc or not Would want there to be versioning Not try and boil the ocean -- RFC, which version Should be able to do the same with EIPs ###### tags: `ethereum` `json-rpc` `community call`

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.