HTTP provider protocol to a gateway about oasis.js HOT 19 CLOSED

from oasis.js.

The easiest first step would be to make a new RPC namespace in the current gateway and do the signing there. Eventually we can pull it out into its own service if we deem necessary. @willscott thoughts?

from oasis.js.

from oasis.js.

Agreed we should do that. As an MVP, however, I think it'd be more efficient to lean on all the gateway machinery we already have. Once we're happy we can easily extract it out.

from oasis.js.

from oasis.js.

The gateway is effectively a relay already. I think we can just use everything there. It seems unnecessary to go through an intermediary relay server when that server can just be a gateway with different CLI args. Am I missing something here?

from oasis.js.

from oasis.js.

we should write it in golang. As much as I love rust, it's not great for everything. Seems like a simple enough service, right? It's just making rpc calls into the enclave anyway.

from oasis.js.

I don't care about the language. My point was to avoid rewriting code thats already written. All this has to do is

• receive RPCs
• maybe make a dashboard request for whitelists?
• estimate gas
• sign transactions
• use the ekiden client to send to the runtime

Am I missing anything here? I'm happy for us to do something new in Go if necessary.

from oasis.js.

The gateway code is not as maintainable as I'd like it to be. It also depends on umpteen traits from parity rpc, which won't exist when, at some point, we cut over from parity. The functionality of the new gateway service seems limited enough in scope that it's a green field project that would benefit from a new stack.

from oasis.js.

Do we have a Go ekiden runtime client, i.e., a Go version of https://github.com/oasislabs/runtime-ethereum/blob/master/gateway/src/client.rs#L136? Generated by https://github.com/oasislabs/runtime-ethereum/blob/master/gateway/src/lib.rs#L91.

from oasis.js.

where would that be used? i thought the dev signing proxy would talk to the current gateway? (if not be integrated with it) - so could just have a geth web3 client?

from oasis.js.

I was hoping that, if we did the proxy in Go, then we could make an RPC to the runtime like the gateway does--so that we can avoid having to deal with failures between signing proxy <--> gateway.

from oasis.js.

i don't know that protocol well. doesn't seem unreasonable to have the dev proxy take on that extra work - though i would imagine it would be separated from pre-compute work, and shouldn't need to have a full runtime embedded.

The dev wanting to control their own wallet is a different motivation from why someone might pay infura or some service to be a gateway on their behalf.

from oasis.js.

A few clarifications: the 100-second websocket timeout is a cloudflare limitation--it has nothing to do with the runtime-ethereum gateway. Also if we define new json-rpc endpoints in the gateway, they can use whatever errors they want--there is no requirement that they use web3 error semantics.

from oasis.js.

Ultimately the mvp could probably be implemented as a couple hundred loc in the gateway--but it would also be straightforward to have a golang relay server that simply sends txns to an existing gateway. I think it's fine either way.

from oasis.js.

I can imagine it to be desirable to want to run both the proxy signer and the gateway together. If we do the Go server, we might consider packaging it together with the gateway.

from oasis.js.

Scoping this issue to HTTP only.

from oasis.js.

Rescoping the issue to just be RPC execution. Event subscriptions and getPublicKey are not yet completed in the developer gateway, so moving them to new issues. See #38 and #37.

This was handled here #34. Event subscriptions and a getPublicKey implementation should follow from the work there.

from oasis.js.