I wish to enquire if there are maximum no. of participants, assets, transaction that hyperledger can support?
Also, is there rollback (ACID compliant, example) if the submission of a transaction fails?
Thank you.
Nathan Aw
I wish to enquire if there are maximum no. of participants, assets, transaction that hyperledger can support?
Of course there will be limits. But they are, for practical purposes, high enough to allow serious work to be done. Participants can take several forms:
organizations with a separate identity and potentially with their own CA, MSP, orders, endorsers, and committers in any combination
roles in chaincodes
identities with a specific role in an organization
The most limited will be organizations and peers etc, but a consortium can still be big enough to accommodate more than a small number of these to my knowledge. Roles and identities are dependent on your needs and the design of your smart contracts. Unless you are stress testing, how many of each do you really need? (Identities will be of course be largest in number, but the system is designed with that in mind, again to my knowledge).
So my point here is that the limits should be adequate for most practical purposes.
Also, is there rollback (ACID compliant, example) if the submission of a transaction fails?
The whole point of a blockchain is to provide a transparent, distributed ledger with perfect consistency at all times. So the answer is yes.
Note, though, that roll-back simply means that at transaction succeeds or fails and that all copies of the ledger will have the identical result. If the transaction fails, then none of its changes will appear in the ledger.
Transaction failure modes:
Fail during endorsement happens when the chaincode chooses to fail the transaction for violation of business rules or for internal errors.
Fail during commit happens when two transactions execute in parallel (for practical purposes that is -- they could execute too close together and get the same effect) and (a) touch the same keys, and (b) end up in the same block. In this case, the endorsers happily create the read / write sets for both, but the committers find that the second transaction is reading an invalid version of a key that was updated by an earlier transaction in the same block. The read / write set is never applied, thus providing the roll-back.
The solution to consistent failures during commit is to add flow control into the application. You cannot solve that in the chaincode.
There is no limit in the number of participants that can take part in an Hyperledger Blockchain. However, they will be private Blockchains, so everybody wouldn't take part on it.
About the fail of the submission of a transaction, it depends on what you mean with it. A transaction could fail when it is send by a user. However, once a transaction starts its trip, it will terminate.
Once a Peer sends a transaction, it waits to get an answer. It could be successfull or not, but it needs an answer. If I were you, I'd read about the transaction flow of a transaction in Hyperledger Fabric. Or about the Basic workflow of transaction endorsement
Related
I can modify Hyperledger's endorsement policy at instantiate time as described in the docs here. However, is there some guideline on how many peers should endorse a transaction?
I understand that not all peers need to be endorsing peers but generally, what would be the minimum acceptable number in terms of total number of peers? Of course it varies from application to application, but would be nice to have some guideline/insights.
what would be the minimum acceptable number in terms of total number
of peers?
The number of peers is of lesser significance than the number of organizations.
The idea behind the endorsement policy, is that the peer block processing logic wants to be able to "know" that the transaction contains a write set (values that mutate the world state) which was executed "correctly".
Now, imagine that you have a chaincode which 3 organizations use.
You would not want to have an endorsement policy of "Org1.member or org2.member or org3.member" because that would mean that if any of the organizations (1,2,3) is malicious, it could dictate anything it wants, and completely ignore the chaincode business rules.
So, ideally you would want to have an endorsement policy that proves that a majority of the organizations agree to a certain execution result, and therefore set it to something like "2 of the 3 organizations".
Next - comes a notion of number of peers.
If you have i.e 10 peers and you are afraid that someone would hack into one or more of them, you could set the endorsement policy to reflect that.
In the "Coffee with Blockchain" app produced by IBM it performs price matching between Growers and Buyers. I'm wondering how that matching would be implemented (either in the example app or in an actual implementation).
Example of the app can be seen here: https://www.youtube.com/watch?v=suE5KHkESF4
How does "Coffee with Blockchain" match growers to buyers?
Some questions to help guide the answer:
Does that matching operate entirely as chaincode? If so, how would that be implemented?
Eg, would the Grower submit a transaction that they have a new batch of beans ready for shipment and that triggers the match-making part in the chaincode to find/choose a Buyer?
I have my doubts on making that process deterministic, otherwise a grower's new batch announcement fails and they'd have to retry. Perhaps there's a different way of doing so in chaincode?
Or does the matching operate outside of the chaincode, listening for updates in the ledger, and instead it calls the API to invoke a chaincode method to transfer the beans from Grower-A to Buyer-B?
My doubt on that though is the matching is then centralized to some trusted provider, rather than validated/endorsed chaincode.
Thanks
I can only hypothesise based on my understanding of Blockchain. IBM's algorithms are not public, so I do not have first hand knowledge.
But from what I know - Yes, all your understanding seem accurate.
Unlike crytocurrency, in physical commodity, the process of 'mining' is subject to availability of the underlying asset. Farmers are like miners and they will have to announce the production of the commodity. This 'announcement' would trigger the match-making process where registered 'buyers' will be matched.
However, just like you I have my doubts on it being fully "chain code" based. Reason for that being the underlying commodity - coffee - is also simultaneously being traded on commodity exchanges and if the "chain code" prices drifts too far from the exchange prices then the marketplace ecosystem would revert back to traditional channels outside of blockchain.
So in a way the commodity exchange is still the "trusted provider" of the pricing match (albeit indirectly).
Like you, I am of the opinion that this implementation creates more questions than solutions.
This video tries to explain some details -> Journey of Coffee on Blockchain
In my opinion, it might works in other way round:
When GROWER-A submits a transaction that they have a new batch of beans ready for shipment, then it is added to a list and it will be triggered when a BUYER-B wants to buy some quantity of bean.
Suppose a BUYER-B wants to buy a new batch of beans(some quantity), then it will trigger the API to invoke a chaincode method to transfer the beans from GROWER-A to BUYER-B.
So from this it can be concluded that, there might be a chance of two chain, chain A for GROWER which will be add on block when GROWER-A wants to submit a bean and remove one block when BUYER-B wants to buy it.
And chain B will be for buyer which will work alternatively.
This video explains the example in detail. Hope it answers some of your questions.
Per this explainer video -
1) Buyer brews a cup of coffee, and hence its stock of coffee beans goes down
2) Buyer buys beans to restock
3) Grower ships beans to the buyer
4) Once the Buyer confirms the receipt of the shipment, grower gets paid
The video also explains:
Coffee beans prices may differ based upon the quality and demand. Quality may be determined by popularity or by a certifying body
All the transactions are governed by Smart Contracts. Each participant in this, say Coffee Business, network - the buyer, the grower, the payment company, the bank, the certifying body, the shipping company, even coffee making machines (read, IoT) - agrees to abide by relevant contract(s)
As far as I know, IBM's Blockchain solution is for Enterprises, and not general public, like Bitcoin Exchange. So, all the enterprises become part of that same network.
I have two queries related to ethereum. I am trying to do a proof of concept that required multiple users to have access to a blockchain node.
(1). Can I have like a million user accounts on Ethereum's Node. Or does ethereum has restriction in the number of accounts.
(2). I want to have user level restrictions in place. So, for instance there are two customers transacting with few other customers. Each of the customers should see his own transaction. Simply said.
For instance, both the below transactions happen on a blockchain node.
A->B 5 USD
C->D 10 USD
A and B should only see 5 USD transaction on their UI.
C and D should only see 10 USD transaction on their UI.
Bank should see both the transactions.
Is the above possible on ethereum or do we have some restrictions on above.
Responses are appreciated
In the public Ethereum network:
Q1: You can have data about as many accounts as you require. Someone pays the gas cost of all state commits. This data is on all verifier nodes, so generally-speaking, everyone has a copy.
Q2: It's possible to design smart contracts to enforce these sorts of rules, but one should keep in mind that all information on the chain is visible to a determined adversary even if the contract(s) is designed to restrict access. Since all nodes verify all transactions, it follows that all data is visible to all nodes.
There are some variants of Ethereum that apply different approaches to verification and confidentiality.
Different between various blockchain protocols
Hope it helps.
Yes ,You can do this by writing some logic which will restrict customer to see some certain transaction and other stuff. this can only be done in front end application. Ethereum is permission-less block chain network which means that every one in network can see all the data. From front end we can stop users but keep in mind still they can view all the transaction or data from Ethereum client console like GETH.
Note:it is not best use case for Ethereum you can use fabric for it.
I'm new to Blockchain but I do understand the concept behind it. My question is can we only contribute to blockchain through chaincodes or can we also create a distributed ledger? And also where does the Ledger gets stored?
There are many ways to implement a distributed ledger, blockchain is one way, but there are many new and exciting alternatives.
For example (prior art), Amandla-3i-Backbone uses an architecture where agents execute on a host. Essentially, a transaction is committed in just over 10 steps.
Amandla-3i-Ecosystem
Step 1
An arbitrary Agent decides to make a transaction. This Agent can be embedded in any product, such as an Android mobile application.
In this example, the application is transferring money to another user.
What is not shown in this step is that the Agent would need to locate a suitable Trade-Agent to conduct the transaction. This could be hardwired into the application, or it could have access to another Trust-Agent that could forward the details of a reputable Trade-Agent.
Step 2
The Agent describes the transaction it wants to the Trade-Agent which will conduct the complex workflow on behalf of the Agent requesting the transaction.
Note that the Agent is renting processing power from it’s local Node, and will be charged by the Trade-Agent for all work done. This monitisation means that economic type attacks are not possible.
The first thing the Trade-Agent does is contact the Buyer-Brokering-Agent directly.
It’s important to note that the Buyer and Seller do not interact directly, because Trust-Agents need to witness each transaction so that Brokering-Agent don’t oversell their currency at a high rate of exchange. An analogy would be a government printing too much money. It would be the Trust-Agents that would need to signal a devaluation in the appropriate Brokering-Agent currency if they witnessed this economic theft from taking place.
Step 3
Just after informing the Buyer-Brokering-Agent of the upcoming transaction, the Trade-Agent connects with a number of Trust-Agents that will witness the transaction. This could be a high number (possibly as much as 7 or more) of Trust-Agents. It is in the interest of the Trade-Agent to authenticate this transaction with a high degree of trust in order for the Trade-Agent to maintain its credibility on the network, since it is also rated by other Trust-Agents. It is likely to choose agents that have verified their execution and code to ensure there is no cheating. Only 2 Trust-Agents are shown on the diagram for descriptive purposes.
Step 4
The Trust-Agents begin the chaperoned trade by connecting to the same Buyer-Brokering-Agent and present the trade that they intend to witness.
Step 5
In the meantime, the original Trade-Agent connects to the seller and establishes the upcoming trade.
Step 6
Also simultaneously, the Trust-Agent also connects with the Seller-Brokering-Agent and signals their role as witness.
Step 7
Once the Seller-Brokering-Agent is informed of the transaction, it also makes a connection directly with the Buyer-Brokering-Agent and performs the chaperoned transaction.
Step 8A and Step 8B
Both the Buyer-Brokering-Agent and the Seller-Brokering-Agent connect to each of the Trust-Agents that are witnessing the transaction as part of the authentication process.
Step 9
The Trust-Agents confirm that the transaction was successful.
Step 10
The Trade-Agent completes the transaction.
Distributed Ledger Transaction Diagram
Example call
Sample call
note: I'm not an expert, I'm a student.
a ledger is composed of the data in the blocks of your blockchain. the schema of the ledger is agreed upon in advance (in the protocol of the blockchain), and trust is assured through the design of the ledger, mechanics of the blockchain, and often the proof of work in writing the next block.
blockchains don't need to be multi-party, they only need to be multi-party to be very useful. blockchains can be distributed by utilizing the network layer, with an eye to scale and trust: a large number of participants or important work should require good proof of work and/or other security measures. Trust can even be ensured by giving certain parties higher rights than others, but this is more useful in industrial uses than in digital currencies.
an example of a network solution that is suitable (but cumbersome) to use for custom blockchains is peerJS (I'm fairly sure it is sufficient). In essence though, the entire thing can be written over connections such as webRTC or raw network connections.
an alternative to writing all of this yourself is to use a general purpose ledger with composable contracts, like etherium or IBM's hyperledger. However, I would argue this is less than ideal for learning about the technology.
In developing a new web service I haven't been able to find very much information on how companies bill for their web services.
Do you bill by request or only certain requests ie) GET or POST?
-would these be tracked at the application or server level?
Do you bill by bandwidth?
-again how would this be tracked on a per user basis
Do you charge a subscription to simply have access?
-this is assuming that they are only granted an api key after payment has been made.
A combination of the above or other options?
Thanks for your help.
As all things in a market economy, the price, but also the inconvenience (or convenience) and risk associated with the actual payment (irrespective of the amount) is a function of how unique and cool and valued your service or product is.
It is therefore impossible to answer the question but in very generic terms, i.e. in the form of suggestions. You actual invoicing model may base on one or several of the following
bill for a one-time setup fee
bill on a subscription basis (i.e. for a defined period, with explicitly defined maximum amounts of usage)
bill for maintenance
bill by the act, i.e. a certain amount (possibly on a decreasing unit price schedule). Such acts should be counted at the server level, (The client-side may include some audit/monitoring/log of sorts, but the server-side should be the authoritative source of info)
bill by volume (for example number of MBytes transfered etc.), this is applicable to services where there is a big variation in the volume of info produced for each "act".
In general, the price and the modality of accounting should seem fair, to both parties, particularly to the buyer, and typically, the simpler the better. The price should not necessarily be low, provided you can make the case that the service provided is effectively valuable, and that you either invested and took risk to introduce the service, or the on-going expenses associated with running the service are evident.
I guess It Depends™ on what the service does. Broadly, I'd say you should bill when you provide some intrinsic value; how you determine what that billing criteria is is quite domain-specific. There may be some property of the service provided which allows you to determine how much to bill.
For example, suppose you've a web service that performs a calculation. You might decide that for every successful computation you do, you're going to charge a fixed fee, say $0.01, but let users off if there's a validation problem, such as an invalid request. Alternatively, if those computations are vaguely long-running, you might have a charging model that's based on some sort of CPU-time metric.
Your point about subscriptions is a good one, and this is an area where you might potentially benefit from allowing a couple of commercial models; one to cater for the users who might perform a lot of requests per month, in which case a fixed subscription might make sense, and one to cater for users who make a few ad-hoc requests. In the latter case, of course, if you only attract those customers, then you're not going to make a good return on investment. Some kind of middle ground, whereby you have a small subscription, but then allow customers to buy a "block" or "bundle" of requests on top without incurring additional processing costs, might work.
Most webservices I know of charge for two things:
Volume of "usage". Generally giving low volumes "free" access (i.e., less than X hits/hour from a given IP address account combination). This is similar to say, twitter which gives you 150 hits/hour to its service from either your username, or unique IP or combination of the two (so you dont abuse it by changing IPs frequently). If you want a higher volume you pay for that access and its usually assigned by account (in twitters case you can get a dev account [for free] which gives you 20K or more hits an hour)
Depth of Details, Access to features. Again free accounts get a minimum amount of access, but dont get access to more data or to more advanced features (filtering, etc). Lots of google services work like this, were base access is given to everyone but if you want more refined abilities (greater search, more data, faster results) you have to buy an account code with the corresponding functionality.
I havent really seen or participated in any projects with pay-for-performance, or pay-per-hit/access models as they get very difficult to reliably bill for and very hard to account for to customers, even if you use tiered or banded ranges. How do you tell your customers how many hits they have used, especially in a distributed system, with redundant fail-over, etc. If I had to pay $0.01 cents per access I would want to know exactly how its measured, and what the company had in place to control access, and how accurate their monitoring was, etc.
Its not impossible, and definitely can be done, and may work well in large bulk scenarios.
Many of the ones I have seen bill by time, such as on a monthly or yearly basis. Some allow you to pay by the month, some require some (or all) of the fee up front. Access might be restricted by issuing a security certificate for the web service that expires when the customer's account expires, or possibly by having them send a client ID and letting the server check if that client ID is allowed to have an answer (but that's open to people stealing someone else's client ID ;) ).
I suppose if you have a service that sends and receives very large amounts of data, it might make sense to bill per service request, but the billing for that could get trickier. Are clients likely to make dozens of requests per day, or just a few? How much to bill per transaction? $100? $0.01? That all would depend on the nature of the service. If you want to go that route, you would probably need to be able to ensure that clients only get billed for requests that are successfully answered (I'd hate to get billed even though my client app failed to receive the entire web service message from your server).
Per request or as a subscription, and yes, bandwidth can be a variable that is used to set the fee. Depends of the value of binding the customer close or having a myriad of loosely coupled customers using it. There is no correct answer to the question that fits all or even most cases.
If I look at the services I have made in the past, the subscription model would be the best model to use. Sometime a tick of $ per request seems like the best approach but I have never had a service configured that way yet.
I agree with what has been said by Rob and Des. One thing to remember is that a subscription is a really simple concept that everyone is used to and comfortable with (if you price it right). If you want to cover a wide audience look at how the payment providers do - they have slightly different methods of payment depending on how many transactions you do per year. There'll be a fixed subscription plus a per-transaction charge and they both vary with the number of transactions. This is the most flexible, but it depends if it makes sense for your business.