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.
Related
I would like to use Hyperledger Fabric to do asset transfers among millions of users.
What I had in mind :
single organization containing millions of users
smart contract that handles asset transfers (asset will be a custom data -like a token)
A DAPP will invoke smart contracts with user identity
I want a private blockchain because there is no gas fees for invoking smart contracts, writing to the ledger and users are known.
I want a trusted ledger so users can check that the asset transfer has been done correctly and no token has been "stole".
Does that makes sense ?
Also who will be the peers ? Some random guys among the users ?
Hyperledger is a consortium blockchain, meaning that only pre-selected participants (organizations who run peers, orderers,...) are involved. This type of blockchain is not open to everyone, but semi-private. A private blockchain has one participant who has control over the rules of the blockchain. This kind of blockchain doesn't have a technically meaningful use case and one should re-thing if database makes more sense. Often an implementation happens either because of lack of knowledge or for marketing reasons (blockchain is a hype and not-knowledgeable users will fall for the buzz-word and trust the implementation).
I've been working on several projects where managers wanted a blockchain for marketing reasons and through out the project we could never justify the use of this technology.
In Hyperledger Fabric we have several roles (user, peer, orderer, ...). They all have identities. Peers are those who run the nodes (node can (doesn't have to) consists of the world state, smart contract,...). A user will have a differnet identity than the peer and will have to be enrolled separately. While it is possible for a user to set up a peer on a machine it isn't a common practice. It would be other organizations that will run peer nodes. For example if you're a bank and want to keep transactions private but still want to establish trust through the blockchain. In this case you would have a consortium blockchain where you could run one node and further ask an insurance company to run another node for you. This is a set-up I would recommend in your case as well.
I have already found many wallets that offer multisig smart contract deployment. But this way is very expensive and slow, because it requires a lot of transactions.
I think there is another way. For example, we can create many private keys, sign transactions with them, and then combine the results into one final transaction.
Is such a scheme possible? Or maybe I missed some services?
Ethereum does not support native threshold wallets. You need to use multisignature wallets like Gnosis Safe.
Gnosis Safe requires only one transaction per execution from the multisig wallet. Other communication happens off-chain. Thus your assumption "very expensive and slow, because it requires a lot of transactions." is incorrect.
Currently, Ethereum protocol only supports smart contract based multisignature wallets. They are very expensive to deploy and they do expose wallet setup: participants of multisig wallet, many of them and what is the minimum amount of confirmation to transfer funds from this wallet. On top of that, smart contract should know how to work with native coins, with different kinds of tokens and be able to handle multiple spending requests. This all adds weight to smart contract and makes it more expensive to deploy and operate.
However, there is a threshold signature system (TSS). In the nutshell it works the following way: all participants generate their own private keys, then they derive their respective public keys and share with others. The group public key is literally a sum of participants public keys. When they need to sign a transaction they calculate their individual shares of r and s values of a signature. This way they literally can just sum up their signature shares and get a group signature. This approach is called multiplicative-to-additive transformation and is a scope of multi party computation (MPC).
The advantage of it is that group does not expose their wallet participants to the world and transaction cost is the same as if that was signed by a normal private key (through a Metamask for example). On top of that, there is no difference what transaction you are signing, coin transfer, NFT token minting or deployment of smart contract.
If you want to try this in action feel free to download multichain multisig wallet: WH Cypher. It supports Bitcoin, Litecoin, Ethereum, ERC20 tokens, BSC, BEP20 tokens and more. There will be more blockchains supported soon. You can setup there any wallet scheme: 2-of-2, 2-of-3, 3-of-5 and so on. There is also test networks avalable: Bitcoin Testnet and Ethereum Ropsten.
Disclaimer: I am a developer of this wallet. Feel free to reach out to me to provide feedback or request new features.
Everything I've been reading about blockchain from my understanding says that even on a private blockchain, every participant can view all transactions. I've seen it mentioned that a use case for block chain could be the sharing of medical data. So for example if I had a blockchain that holds the medical history of every person from birth to death in a country. Is there no way of setting up permissions so that only data relating to a person and those who have been given permission to that person's data can view it? If the data is stored on every node in a blockchain, how is a person's computer supposed to have the capacity to store the medical data of every person in a country?
I would advise looking up Medrec when related to health care. Most of the research is geared towards dealing with keeping the data off the chain. In addition, there are other blockchains that might provide a better solution, for more privacy, for example, I would look up quorum by JP Morgan. There are different formats being looked at but these can give you two possible solutions. Also, check out Health Nexus' whitepaper, it deals with medical blockchain technology. Let me know if you need more.
https://www.pubpub.org/pub/medrec
https://github.com/jpmorganchase/quorum
There are blockchains that allow defining permissions. Hyperledger Fabric is one of them. You have the ability to configure channels with data stored in the ledger of the participants in the channel only.
to pass the scalability problem of blockchains and their solutions for this purpose, you should concentrate on off-chain architecture.
right now this scenario should be considered:
save tx's to the blockchain(it should be formal)
save hashed data to an off-chain repository like DB's.
save the address of that data-hash to blockchain for future access.
yeah, you pointed to the right thing. a central point of access as an admin-node or god should be the opposite of blockchain as a distributed dream.
for this issue, the mechanism like secret-sharing or re-encrypt proxy should be realized to guarantee the privacy and security of data-hashed.
for more information read this article:
https://www.sciencedirect.com/science/article/pii/S2210670717310685
GoQuorum has an 'enhanced permissioning' model where you can do all that, and at the same time stay compatible with Ethereum standards.
Check this out: https://consensys.net/docs/goquorum/en/latest/configure-and-manage/manage/enhanced-permissions/
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
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.