Get scalable test-net RPC in place about metamask-extension HOT 15 CLOSED

Should also include a scalable IPFS provider.

from metamask-extension.

caktux (Vincent) is working on a scalable back-end for most of ConsenSys dapps.

from metamask-extension.

https://github.com/consensys/storm

from metamask-extension.

some notes on linking ethereum nodes to each other:
https://gist.github.com/tgerring/eae5e85bd62664d2f25d
https://gist.github.com/tgerring/6f274a999cab1d58a617
https://gist.github.com/kumavis/4c339a5e3284fb11af02

from metamask-extension.

> admin.nodeInfo.enode
"enode://1118980bf48b0a3640bdba04e0fe78b1add18e1cd99bf22d53daac1fd9972ad650df52176e7c7d89d1114cfef2bc23a2959aa54998a46afcf7d91809f0855082@[::]:30303"

from metamask-extension.

root@3cccae064ef0:~/.ethereum#  geth --exec "admin.nodeInfo.id" attach
"db1adb7c13a480c525beffb80be08c9b08c8fb9b1f204a3ea40b141b4a18bae10301561bbdaded9d24478987095d3b0c62b7bc2c79f6a3fd235e215de5935122"

root@3cccae064ef0:~/.ethereum# geth --exec "console.log(admin.nodeInfo.id)" attach
db1adb7c13a480c525beffb80be08c9b08c8fb9b1f204a3ea40b141b4a18bae10301561bbdaded9d24478987095d3b0c62b7bc2c79f6a3fd235e215de5935122
undefined

from metamask-extension.

kumavis [12:13 PM] 
@wanderer: how are enode ids derrived from their private keys?

[12:15] 
e.g. `0945ced4c0203eef7155bdb37ffb50407ee0dab550eb0a2c0592badecd0eaa77` -> `db1adb7c13a480c525beffb80be08c9b08c8fb9b1f204a3ea40b141b4a18bae10301561bbdaded9d24478987095d3b0c62b7bc2c79f6a3fd235e215de5935122`

[12:15] 
is that just a secp256k1 pub key?

wanderer [12:15 PM] 
yep

from metamask-extension.

Nick found that Etherscan is already hosting a livenet RPC.

It doesn't support the exact normal RPC methods (requires a queryparam to declare the RPC method), but I've already started building the required subprovider on this branch here.

It's basically 100% copypasta from the RPC subprovider. The relevant difference is this line.

Long term it could easily subclass from a normal RPC provider, if the RPC provider simply broke out its url-building method, so it could be overridden by providers like this one.

from metamask-extension.

For this to work we just need to add configuration-based subproviding, so that instead of just setting an RPC url, the config should be able to declare exactly which provider to use also.

from metamask-extension.

I've started designing this extensible configuration in #80

from metamask-extension.

The extensible config is in place, I'm now working on getting Metamask running on the etherscan provider on this branch, but right now it's not working.

This is basically my first time really diving into the provider-engine, so there will probably be some learning curve for me without assistance. @kumavis

from metamask-extension.

Issues are:

• The ethStore is not defined when connection receives its first remote event.
• This provider does not have a sendAsync method.

from metamask-extension.

Ok so I figured that part out, we're now subclassing zero-client to accept an etherscan option that lets it use that subprovider.

However, that subprovider is not yet providing every method we need it to, so some more work to be done there.

easy to follow my progress here.

from metamask-extension.

@FlySwatter can you list the missing rpc methods?

from metamask-extension.

Looks like just one left:

• getTransactionByBlockNumberAndIndex

(That's remaining methods that etherscan supports, they have been adding even over this week, so they may get closer to complete as well. The summary of that state is nicely captured in the opening comments of the etherscan provider).

from metamask-extension.