diff --git a/v1.3.1/404.html b/v1.3.1/404.html new file mode 100644 index 000000000..7e328f5e7 --- /dev/null +++ b/v1.3.1/404.html @@ -0,0 +1,3317 @@ + + + +
+ + + + + + + + + + + + + + +Hyperledger FireFly has a multi-tier pluggable architecture for supporting blockchains of +all shapes and sizes. This includes a remote API that allows a microservice connector to +be built from scratch in any programming language.
+It also includes the Connector Toolkit, which is a pluggable SDK in Golang that provides +a set of re-usable modules that can be used across blockchain implementations.
+++This is the preferred way to build a new blockchain connector, if you are comfortable +with coding in Golang and there are language bindings available for the raw RPC interface +of your blockchain.
+
The core component of the FireFly Connector Framework for Blockchains is a Go module +called FireFly Transaction Manager (FFTM).
+FFTM is responsible for:
+Submission of transactions to blockchains of all types
+Protocol connectivity decoupled with additional lightweight API connector
+Easy to add additional protocols that conform to normal patterns of TX submission / events
+Monitoring and updating blockchain operations
+Receipts
+Confirmations
+Extensible transaction handler with capabilities such as:
+Nonce management: idempotent submission of transactions, and assignment of nonces
+Transaction process history
+Event streaming
+The framework is currently constrained to blockchains that adhere to certain basic principals:
+Has transactions
+That are signed
+That can optionally have gas semantics (limits and prices, expressed in a blockchain specific way)
+Has events (or "logs")
+That are emitted as a deterministic outcome of transactions
+Has blocks
+Containing zero or more transactions, with their associated events
+With a parent hash
+Has finality for transactions & events that can be expressed as a level of confidence over time
+Confirmations: A number of sequential blocks in the canonical chain that contain the transaction
+The nonces for transactions is assigned as early as possible in the flow:
+This "at source" allocation of nonces provides the strictest assurance of order of transactions possible, +because the order is locked in with the coordination of the business logic of the application submitting the transaction.
+As well as protecting against loss of transactions, this protects against duplication of transactions - even in crash +recovery scenarios with a sufficiently reliable persistence layer.
+FFTM is optimized for cases where all transactions for a given signing address flow through the +same FireFly connector. If you have signing and nonce allocation happening elsewhere, not going through the +FireFly blockchain connector, then it is possible that the same nonce will be allocated in two places.
+++Be careful that the signing keys for transactions you stream through the Nonce Management of the FireFly +blockchain connector are not used elsewhere.
+
If you must have multiple systems performing nonce management against the same keys you use with FireFly nonce management,
+you can set the transactions.nonceStateTimeout
to 0
(or a low threshold like 100ms
) to cause the nonce management
+to query the pending transaction pool of the node every time a nonce is allocated.
This reduces the window for concurrent nonce allocation to be small (basically the same as if you had +multiple simple web/mobile wallets used against the same key), but it does not eliminate it completely it.
+The "at source" approach to ordering used in FFTM could be compared with the "at target" allocation of nonces used in +EthConnect).
+The "at target" approach optimizes for throughput and ability to send new transactions to the chain, +with an at-least-once delivery assurance to the applications.
+An "at target" algorithm as used in EthConnect could resume transaction delivery automatically without operator intervention +from almost all scenarios, including where nonces have been double allocated.
+However, "at target" comes with two compromises that mean FFTM chose the "at source" approach was chosen for FFTM:
+Individual transactions might fail in certain scenarios, and subsequent transactions will still be streamed to the chain. + While desirable for automation and throughput, this reduces the ordering guarantee for high value transactions.
+In crash recovery scenarios the assurance is at-least-once delivery for "at target" ordering (rather than "exactly once"), + although the window can be made very small through various optimizations included in the EthConnect codebase.
+The transaction Handler is a pluggable component that allows customized logic to be applied to the +gas pricing, signing, submission and re-submission of transactions to the blockchain.
+The transaction Handler can store custom state in the state store of the FFTM code, which is also +reported in status within the FireFly API/Explorer on the operation.
+A reference implementation is provided that:
+eth_gasPrice
for EVM JSON/RPC)The reference implementation is available here
+One of the largest pieces of heavy lifting code in the FFTM codebase, is the event stream +support. This provides a WebSocket (and Webhook) interface that FireFly Core and the Tokens +Connectors connect to in order to receive ordered streams of events from the blockchain.
+The interface down to the blockchain layer is via go channels, and there are lifecycle +interactions over the FFCAPI to the blockchain specific code to add and remove listeners +for different types of blockchain events.
+Some high architectural principals that informed the code:
+One of the most important roles FireFly has, is to take actions being performed by the local apps, process them, get them confirmed, and then deliver back +as "stream of consciousness" to the application alongside all the other events that are coming into the application from other FireFly Nodes in the network.
+You might observe the problems solved in this architecture are similar to those in a message queuing system (like Apache Kafka, or a JMS/AMQP provider like ActiveMQ etc.).
+However, we cannot directly replace the internal logic with such a runtime - because FireFly's job is to aggregate data from multiple runtimes that behave similarly to these:
+So FireFly provides the convenient REST based management interface to simplify the world for application developers, by aggregating the data from multiple locations, and delivering it to apps in a deterministic sequence.
+The sequence is made deterministic:
+The core architecture of a FireFly node can be broken down into the following three areas:
+What fundamentally is a node - left side of the above diagram.
+What are the core runtime responsibilities, and pluggable elements - right side of the above diagram.
+Connectors
and Infrastructure Runtimes
.Connectors
are the bridging runtimes, that know how to talk to a particular runtime.Infrastructure Runtimes
are the core runtimes for multi-party system activities.What is the code structure inside the core.
++++
+- A reconciliation is underway to ensure the medium-level view correlates well with this code structure.
+
This demonstrates the problem that at its core FireFly is there to solve. The internal plumbing complexity of just a very simple set of Enterprise blockchain / multi-party system interactions.
+This is the kind of thing that enterprise projects have been solving ground-up since the dawn of enterprise blockchain, and the level of engineering required that is completely detached from business value, is very high.
+The "tramlines" view shows how FireFly's pluggable model makes the job of the developer really simple:
+This is deliberately a simple flow, and all kinds of additional layers might well layer on (and fit within the FireFly model):
++This diagram shows the various plugins that are currently in the codebase and the layers in each plugin
++This diagram shows the details of what goes into each layer of a FireFly plugin
+The FireFly node is built for extensibility, with separate pluggable runtimes orchestrated into a common API for developers. The mechanics of that +pluggability for developers of new connectors is explained below:
+This architecture is designed to provide separations of concerns to account for:
+