Support for public blockchains

[glesaint]

Background

EthConnect was initially designed as a bridge into Ethereum permissioned chains. These chains usually are running a PoA/IBFT consensus algorithm, where the finality of transactions is guaranteed. These chains are usually configured with a gas price of 0, so that transaction fees are not required. Lastly, the permissioned chain provider usually offers a integrated signing service. Users of public blockchains have similar needs for an ESB/EAI integration in many cases, which EthConnect could fulfill provided that features are built to support other scenarios than those outlined above.

Motivation

It's beneficial for the community to have a product that addresses the needs of public, and private chain users, so that developers working on the Ethereum platform have a set of tools available to them that can address any requirement for integration. At first sight, the work required to enable this in EthConnect does not seem to have any roadblock.

Requirements

Gas Price

• Public network transactions usually fetch a gas price from a 3rd party source such as ethgasstation.info for a desired confirmation time
• EthConnect should allow to send a transaction with high/medium/low speeds, or even a target confirmation time (e.g. 1mn, 15mn, 1hr)
• EthConnect should keep track of transactions confirmations, and allow to rebroadcast transactions with a higher fee when the desired confirmation speed is not achieved

Finality

• Finality on public networks is usually defined in terms of number of block confirmations
• Transactions can enter the transaction pool, and exit it after some time (E.g. dropped by a node)
• EthConnect should not assume finality but instead allow users to define the required number of block confirmations
• For security reasons, we usually also verify the number of confirmations from multiple attesting parties

External Signing

• EthConnect signs transactions directly currently
• On public networks, a variety of signing solutions (e.g. metamask, hardware wallet, custodian service) would be used
• If we want to continue to rely on ethconnect for ordering and nonce, EthConnect should allow to use an external signing service
• Perhaps a signing request feature should be introduced that's separate from the signing itself that could happen on another service

Events Detection

• On public networks, transactions that have been confirmed can, in rare cases, then disappear
• These scenarios occur when a transaction is confirmed on a block that ends up being an uncle in Ethereum
• The events notification/stream should be amended so that a 'Orphaned' status is used for such transaction states, for example

Outline

To be discussed with the community on how the above can be implemented.

[peterbroadhurst]

I think there is a significant architectural point to consider, when you take a few of the above requirements into account.

Currently Ethconnect functions in a single "nonce assigned at end" mode. It performs streaming based nonce management as close as possible to a target node, and for any given from address it makes sure all nonce management is performed using the transaction pool of one node at any given time.

A stream of transactions flows in order from parallel submitting REST API calls that add unsigned transaction JSON payloads to a queue, through to the "processor", which delivers batches of transactions into the chain by assigns nonces as part of the last phase in the pipeline. This means signing (internal and/or external) occurs at this last phase of the pipeline - as this is the point at which nonces are known.

The signing itself can be internal to the ethconnect code, or external. Both have been performed with the code as it is today, and extending the plug-point for new consumers of the codebase to plug in signing in new ways would be simple.

This model is great for allowing the applications to be highly parallel, submitting REST API requests to the ethconnect tier. By plugging in the optional Kafka layer, it provides a very reliable stream of transactions, that allows applications to submit bursts of transactions very quickly.

With Kafka included, it also allows the nodes to be parallel. The "consumer group" concept in Kafka allows for multiple nodes to be placed down-stream of ethconnect, while still maintaining the integrity of the architecture where there is a single stream of ordered transactions. Kafka partition management (using the from address, or a custom ordering context) allows multiple separately ordered queues to exist.

So how does all this relate to the above...

Well there are two things hinted at in these requirements that might mean introducing a fundamentally new mode of nonce management to the technology, or some other significant creative architectural thinking:

Allowing applications to "pre-sign" transactions, at the front of the pipe.

It wasn't clear this is absolutely required from the comment, but it was implied when mentioning a couple of technologies like metamask etc. Because nonces are part of the signed transaction payload, this means any change to the nonce assigned to the transaction requires a re-signing. So the HTTP contract with applications at the front side of ethconnect would be radically changed by introducing a fully-fledged "nonce assigned at start" approach.

Here it would be much more like a feedback loop with the submitting applications, where it would say something like:

1. I would like to submit a transaction - what nonce should I use
   • Note this means a new set of nonce management state in ethconnect at the front-side
2. Submit with "best guess" nonce given back
3. Get notified asynchronously via events, when key events occur
4. If one of these events requires the transaction to be signed again (new nonce etc.), then return to (1)

Individual management/re-ordering of transactions

Also implied in the requirements, is that individual transactions have a life that's policy-driven.

Rather than being just another transaction in an ordered queue, they are unique transactions that might need to be guided onto the chain, over periods of main minute/hours, and other transactions might be going ahead/behind them.

This again would imply a much richer feedback loop, based on a stateful store, with a UI/API management tier to see what state various transactions are in.

For this layer, I'm not sure that the ethconnect connector itself is the right home within the FireFly stack. It might be better to pull this back out into a plugin within FireFly that takes the operation construct that exists at that layer, and performs policy based decisions around re-submission and management.

e.g. FireFly core (with plugins) becomes the application involved in the feedback cycle mentioned in 1-4 above.

Summary

The picture you've painted for me through these requirements is something like:

|--------------|                      |----------------| --- submission ---> |--------------------------|
| business app |  --- fire&forget --> | FireFly core   |        loop         | ethconnect (/fabconnect) |
|--------------|                      |----------------| <--- feedback ----- |--------------------------|
                                              |
                                       ----------------
                                       | policy engine |
                                       ----------------