I am trying to understand how the "transaction mempool" works in Hyperledger. I am mainly looking at the documentation here: http://hyperledger-fabric.readthedocs.io/en/release-1.1/peers/peers.html#peers-and-orderers
I know how bitcoin works and I am thinking in 'bitcoin' terms (hence the word 'mempool')
So as I understand it, in hyperledger there are 3 parties: application, peers and orderers. All parties have permission credentials from the MSP. The application submitting a transaction first needs to aquire a sufficient number of endorsements from a number of peers. After it appends to the transaction these endorsements, it sends it to an orderer that puts it in its 'mempool'.
In the documentation it clearly states that forks can't happen, and if a transaction is included in a block is final.
My question is: after the application receives the endorsements and sends the transactions to an orderer, how can we be sure that it doesn't send it to another orderer? And what would happen if two different orderers had the same transaction in their memory (before posting the relevant block)?
There is no concept of mempool in Hyperledger Fabric. Ideally in a production environment, all transactions gets written to a Crash Fault Tolerant Kafka cluster, which gives a single view of all the transactions to all the ordering service nodes. Orderers read back from the Kafka to cut blocks of Transactions, they do not send it to other orderers.
You can read more about it in my answer here: Transactions order in a channel with multiple Orderers
Related
I am trying to self-bridge a mosquitto broker. Let me explain the scenario for which I am doing this.
We have 2 parts to our application. One which is concerned with processing data and other is a modbus service that reads data from PLC devices.
The processing part of the application is capable of handling multiple clients. I want to setup a test and a production tenant for the same client. The reason behind this is that this would give our clients the liberty to play around with the test tenant where as the production won't be affected by this.
The test client both sends as well as receives data from the broker. It is important that we don't send the test tenant's data to our modbus service. The topics follow the following format.
company/service/test/+ for the test client and company/service/prod/+ for the prod client.
The modbus service send data to the same broker in the format company/service/prod/+.
Is there a way for me to remap this topic to company/service/test/+ so that both test and prod clients can receive data from the broker.
address 127.0.0.1:41888
topic /company/values/prod/+ in 2
topic /company/values/prod/+ out 2 "" /company/values/test/+
remote_clientid test
remote_username mqttuser
remote_password broker-123
Remember I have a single broker instance and I'm trying to self bridge on this.
In my above configuration, the remapping doesn't happen cause it's not a valid prefix.
Can someone please help me figure out how to approach this?
The problem is the + on the end of the output topic mapping in
topic /company/values/prod/+ out 2 "" /company/values/test/+
You want
topic + out 2 /company/values/prod/ /company/values/test/
This will strip off /company/values/prod/ and replace it with /company/values/test/
You also want to remove the first topic line (topic /company/values/prod/+ in 2 ) as this will lead to an infinity publish loop for any message published to /company/values/prod/+
p.s. starting topics with a leading / while valid in the spec is a REALLY bad idea, as it breaks things when you get round to needing shared subscriptions and injects an unneeded null to the start of every topic.
In MQTT, if you publish to a topic where there is no subscriber for, the message gets dropped.
While this is fine for classic pub/sub messaging, it is not so great for shared subscriptions (which have been introduced in MQTT 5), since this pattern is typically used for some kind of job queue, and you usually don't want to drop jobs just because there is no worker there right now (maybe it just crashed and is restarting).
Is it possible to tell MQTT servers not to drop messages, at least for shared subscriptions, even if there are no subscribers right now? If so, how?
PS: This is not just a persistent session, since I do not want to keep the subscriptions per client. It's more like a "persistent session" that spans multiple clients.
I don't know if any of the brokers supporting MQTT v5 shared subscriptions support this, but I can foresee a way it could work in a way that is line with the spec and spirit of pub/sub messaging.
A MQTT broker will queue messages for topics subscribed to at QOS 1 or 2 for a client that is currently offline, with a persistent session. So I see no reason why shared subscriptions should be any different. I can see it might be a little bit more technically complicated to implement but should be possible (You would need to treat the shared group as a single session).
That said I think the main focus for shared subscriptions is load balancing, followed by HA. So unless you are running all your shared subscribers on the same machine it should be unlikely that they all fail at the same time.
Understand that Interledger is an open protocol suite for sending payments across different ledgers -- supports and integrates with Bitcoin, Ethereum (IS 20022)
Does Interledger supports hyperledger and/or vice versa? i.e., any integration possibilities between Interledger and Hyperledger? i.e., hyperledger <-> interledger <-> ethereum and/or bitcoin?
Understand that Hyperledger does not have cryptocurrency but I might have digital assets within my hyperledger network that can be exchanged with ether or bitcoin.
Thus I wish to know if there are integration possibilities between Hyperledger and Interledger?
Interledger is a protocol, not a system so I would rephrase your question as:
I wish to know if there are integration possibilities between Hyperledger and other ledgers using Interledger?
The answer is yes but this depends also on the use case. What do you mean by "integration"?
Interledger defines some standards for distributed transaction execution according to a two-phase commit strategy. It is specifically well-suited to transfers of digital assets across multiple ledgers because it's resiliency is depends on the economic incentives of the intermediaries to claim the assets that have been transferred to them (and in so doing providing the key to the next intermediary to do the same).
The most important standard is the use of a SHA-256 hash in the prepare request and the pre-image of that hash as the commit trigger of the two phase asset transfer on each ledger. We call the hash a condition and the pre-image the fulfillment.
If you want to perform a transaction that transfers digital assets from a sender on one ledger to a receiver on another ledger then you will first establish a condition that can only be fulfilled by the receiver (i.e. only the receiver knows the pre-image).
This way you can involve an untrusted intermediary that will accept a transfer on the sender's ledger and make a corresponding transfer to the receiver on their ledger. Both transfers are prepared using the condition and when the receiver releases the fulfillment to their ledger the assets are transferred to them.
The intermediary will then have possession of the fulfillment (they observed the assets they transferred to the receiver being committed) and will use the same fulfillment to claim the assets transferred to them by the sender.
Any Hyperledger ledger that can be used to underwrite asset ownership and support this two-phase commit strategy can be used in an Interledger payment.
There are examples of writing smart contracts that do just this in Ethereum so I assume the same could be achieved using Fabric, Sawtooth or any other Hyperledger ledger.
I am not aware of any existing implementations of such a plugin that would allow the reference ILP connector to be run as an intermediary between a Hyperledger ledger and other ILP-compatible ledgers but I'd certainly welcome any efforts to build one and would be happy to assist.
Interledger looks to be a service that wants you to route financial transactions through them. There is some simple sample code for compatible wallets and transactions in JavaScript. Presumably you can do this in any language.
Which leads me to point out that Hyperledger supports smart contracts and applications written in Go, Java, Python, and JavaScript (through the Hyperledger Composer) and so there is a pretty good chance that you can implement an ISO 20022 / Interledger compatible data model and protocol.
HOWEVER
You need to follow best practices and smart contracts should never directly update external services as their is no way of rolling back external service changes if the smart contract sends successful external transactions but then fails for other reasons.
So, you need to design multi-stage transactions in your smart contracts and related applications. Applications will have to coordinate with smart contracts and post on their behalf to other services, recording results in the ledger and triggering next stage updates and transactions.
This allows the blockchain ledger to reflect the reality of external states from Interledger or whatever ISO 20022 compatible service you use.
This all presumes that the other financial institution refuses direct participation with the smart contract and hyperledger blockchain, which is always going to be more efficient, reliable, and secure.
It sounds like you want something like Hyperledger Quilt, which interoperates between different blockchain technologies.
I wish to implement a contract that is subject to market data which each user has access to in their own LAN, but which they are not licensed to share over the internet. I understand that chaincode is supposed to be deterministic. Does this mean that it is not designed to tolerate referencing out-of-band data (data not available in the log or state) - so it would be hazardous in this protocol to reference this market data from chaincode?
Hyperledger Fabric (version 1.0) gives you the chance to create your own distributed networks, via channels. When you create a channel, you decide which are the participants of it, and you isolate them from the rest of the network. Then, you deploy, instantiate and invoke your chaincode, via that channel. So that, you don't share that chaincode and the transactions with all the people/network.
When you execute a transaction, you do it using some parameters. You would define it in your chaincode. You decide whether your chaincode could get parameters or not.
I have found many different questions in your question. Could you specify more wich is your issue?!
I am using rabbitmq to communicate between microservices written in ruby on rails. Each service subscribes to a topic. All services are scaled and run as multiple instances based on need.
During subscription bunny moves all the messages from the queue into unacked state. This makes other scaled instances to be just idle, since there is no message in ready state.
Is there a way to limit the number of messages a subscription can fetch, so that other instances can take the remaining messages from the queue.
Based on the information you made available, I'm assuming you're using rubybunny. If this assumption is incorrect (there are other ruby clients available for rabbitmq) let me know and/or check the documentation related to your client.
Back to rubybunny, link provided points to necessary information, quoting it:
For cases when multiple consumers share a queue, it is useful to be
able to specify how many messages each consumer can be sent at once
before sending the next acknowledgement.
In AMQP 0.9.1 parlance this is known as QoS or message prefetching.
Prefetching is configured on a per-channel basis.
To configure prefetching use the Bunny::Channel#prefetch method like so:
ch1 = connection1.create_channel
ch1.prefetch(10)