You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -113,7 +113,7 @@ contracts and sending transactions, because it is:
113
113
114
114
Instead thick client libraries such as [web3.js](https://github.com/ethereum/web3.js/), [web3j](https://github.com/web3j/web3j), [web3.py](https://github.com/ethereum/web3.py), [Nethereum](https://github.com/Nethereum/Nethereum) and [ethjs](https://github.com/ethjs/ethjs) are used to submit transactions.
115
115
116
-
These thick client libraries perform many of the same functions as hyperledger/firefly-ethconnect, simplifying submission of transactions, receipt checking,
116
+
These thick client libraries perform many of the same functions as hyperledger-firefly/ethconnect, simplifying submission of transactions, receipt checking,
117
117
nonce management etc.
118
118
119
119
In the modern world of Microservice architectures, having a simple, efficient
@@ -141,7 +141,7 @@ Providing a Messaging layer with at-least-once delivery and message ordering, al
141
141
142
142
Applications that have their own state stores are able to communicate over Messaging / Kafka with simple JSON payloads to stream transactions into a scalable set of Ethereum nodes, and process the replies as they occur. The application can scale horizontally. Applications can also be decoupled from the Ethereum network with an integration technology like an Enterprise Service Bus (ESB).
143
143
144
-
When spikes in workload occur that create a large queue of transactions that need to be fed into the Ethereum network at a lower rate, the hyperledger/firefly-ethconnect bridge feeds them in at an optimal rate.
144
+
When spikes in workload occur that create a large queue of transactions that need to be fed into the Ethereum network at a lower rate, the hyperledger-firefly/ethconnect bridge feeds them in at an optimal rate.
145
145
146
146
### Ethereum Webhooks and the REST Receipt Store (MongoDB)
147
147
@@ -172,17 +172,17 @@ A capped collection can be used in MongoDB to limit the storage. For example to
172
172
The transaction pooling/execution logic within an Ethereum node is based upon the concept of a `nonce`, which must be incremented exactly once each time a transaction is submitted from the same Ethereum address. There can be no gaps in the nonce values, or messages build up in the `queued transaction` pool waiting for the gap to be filled (which is the responsibility of the
173
173
sender to fill). This allows for deterministic ordering of transactions sent by the same sender.
174
174
175
-
The management of this `nonce` pushes complexity back to the application tier - especially for horizontally scaled Enterprise applications sending many transactions using the same sender. By using an ordered Messaging stream to submit messages into the Ethereum network, many applications are able to delegate this complexity to hyperledger/firefly-ethconnect.
175
+
The management of this `nonce` pushes complexity back to the application tier - especially for horizontally scaled Enterprise applications sending many transactions using the same sender. By using an ordered Messaging stream to submit messages into the Ethereum network, many applications are able to delegate this complexity to hyperledger-firefly/ethconnect.
176
176
177
-
The hyperledger/firefly-ethconnect bridge contains all the logic necessary to communicate with the node to determine the next nonce, and also to cope with multiple requests being in flight within the same block, for the same sender (including [with IBFT](https://github.com/ethereum/EIPs/issues/650#issuecomment-360085474)).
177
+
The hyperledger-firefly/ethconnect bridge contains all the logic necessary to communicate with the node to determine the next nonce, and also to cope with multiple requests being in flight within the same block, for the same sender (including [with IBFT](https://github.com/ethereum/EIPs/issues/650#issuecomment-360085474)).
178
178
179
179
When using the bridge, an application can submit simple YAML/JSON formatted transactions
180
180
in a highly parallel way across many instances using the same sender address to the bridge
181
181
over HTTPS/Kafka _without_ a nonce. Then through ordered message delivery and nonce management
182
-
code within the hyperledger/firefly-ethconnect bridge it will be assigned a nonce and submitted
182
+
code within the hyperledger-firefly/ethconnect bridge it will be assigned a nonce and submitted
183
183
into the Ethereum node. The nonce assigned is returned by the bridge in the reply.
184
184
185
-
If a sender needs to achieve exactly-once delivery of transactions (vs. at-least-once) it is still necessary to allocate the nonce within the application and pass it into hyperledger/firefly-ethconnect in the payload. This allows the sender to control allocation of nonces using its internal state store / locking.
185
+
If a sender needs to achieve exactly-once delivery of transactions (vs. at-least-once) it is still necessary to allocate the nonce within the application and pass it into hyperledger-firefly/ethconnect in the payload. This allows the sender to control allocation of nonces using its internal state store / locking.
186
186
187
187
> There's a good summary of at-least-once vs. exactly-once semantics in the [Akka documentation](https://doc.akka.io/docs/akka/current/general/message-delivery-reliability.html?language=scala#discussion-what-does-at-most-once-mean-)
188
188
@@ -209,12 +209,12 @@ trivially. Some examples as follows:
209
209
## Why Kafka?
210
210
211
211
We selected Kafka as the first Messaging platform, because Kafka has message ordering and scale characteristics that are ideally suited to the Ethereum transaction model:
212
-
- Transactions can be sprayed across partitions, while retaining order of the transactions for a particular sender. Allowing independent and dynamic scaling of the application, hyperledger/firefly-ethconnect bridge and Go-ethereum node components.
212
+
- Transactions can be sprayed across partitions, while retaining order of the transactions for a particular sender. Allowing independent and dynamic scaling of the application, hyperledger-firefly/ethconnect bridge and Go-ethereum node components.
213
213
- The modern replication based cloud-native and continuously available architecture is ideal for Hyperledger projects, and is likely to be a good fit for the modern Microservice architectures that are common in Blockchain projects.
0 commit comments