How can a malicious activity be controlled in hyperledger fabric ?
Any links will be helpful too.
Fabric is an implementation of the Blockchain. Blockchain guarantees safety because it is a distributed system. The information is replicated in different nodes in the network. So, if you changed one, the other nodes would realize.
On the other hand, a Blockchain is a chain composed by blocks that store transactions. Each block references to the previous one, so if you wanted to modify the data in one block, you should change all the blocks. And this is computationally very difficuatl, you should have more than the 51 % of computing capacity of the network.
You can read more about it here.
You can control through put txt and a potential maximum per port or user per second.
Create a transaction fee which would limit what they are doing if they are taxing the network.
Kick them off the network.
Related
By default someone can read the state data using REST API. Is there a way to add read permissions on specific addresses and change them while the network is up.
The short answer to your question is by using a proxy server, the documentation you're referring to in the question mentions it here https://sawtooth.hyperledger.org/docs/core/releases/1.1/sysadmin_guide/rest_auth_proxy.html#using-a-proxy-server-to-authorize-the-rest-api
There may not be an out of the box component that does what you're asking. There's definitely possibility of doing what you're asking for. You can add the logic filtering based on the read address in the proxy server.
More explanation:
If you're considering one Validator instance per organization. Organization participates in a blockchain application use case then all the participants in the network can see the data you store in the state store. It's the responsibility of the participating organizations to restrict the access to their data. Using the proxy server is one such means.
If you're considering adding multiple use cases per organization, participating in different network altogether then it is advisable to have a different Validator instance per those use cases that require isolation. Again, it's the responsibility of each organization to protect the data stored in the network they're participating in.
For the point 2, the Hyperledger Sawtooth 2.0 proposed solution allows you to run multiple instances of the Validator as a service in a single process. That means you can have one physical node (also process) participating in multiple circuits providing isolation.
Before I end the answer for the benefit of others searching for an answer: Blockchain is not just a distributed storage but also a decentralized network. There are number of design patterns that allows us to keep the critical data outside the blockchain network and use the functionalities of the blockchain network (achieving consensus, smart contract verification to be specific) for what it is expected to do.
If I develop an online application using Blockchain and I have three parties(or peers) required to reach consensus then Do I need a node for each of the three participants or the one node is enough. what I am not able to understand is how I will maintain a node or nodes.
I will be maintaining the database at one location?
First understand that blockchain architecture is not as normal client-server architecture.
In normal client-server architecture, client can change entries that are stored on a centralized server. By changing master copy, whenever a user accesses a database, they will get the updated version.
This is not at all the same as with blockchain technology.
A blockchain is a mesh network of computers linked not to a central server but rather to each other. Computers in this network define and agree upon a shared state of data and adhere to certain constraints imposed upon this data. For a blockchain database, each participant maintains, calculates and updates new entries into the database. All nodes work together to ensure they are all coming to the same conclusions, providing in-built security for the network. Database are distributed across the participant nodes and transactions are immutable.
How the blockchain will maintain different nodes?
Through the use of a peer-to-peer network and a distributed timestamping server, a blockchain database is managed autonomously.
For a production network of three parties (in Hyperledger Fabric we use the term 'organizations') you would likely want to have a network of multiple (2 or more) peer nodes per organization for crash tolerance and increased resilience. You would also likely want to run these peer nodes on different host nodes in different data centers or cloud availability zones.
What happens in Hyperledger Fabric on a private channel block-chain consisting of only two peers if one of the peers is faulty and manipulates it's private block chain?
So the two copies of the block chain will diverge and finally it will be impossible for a consensus algorithm to tell which one is correct.
Is this a valid problem? If so, how would this be mitigated? Would it help to add additional peers to the channel (e.g. placed at a regulator's data center) which are not in control of the two peers mentioned above? Or is there a better solution to tackle this problem?
Adding additional peers to each organization would defend against any single node becoming compromised. Adding additional nodes to the channel(s) at an independent 3rd party (auditor, regulator, or other trusted provider) would be another valid strategy to defend against a counter-party with malicious intent.
The consensus is achieved in the Ordering Service, the Peers are independent from it. I think that they are two different things:
The Peers don't manipulate the Blockchain. They could send incorrect or invalid transactions. The result of the execution of those transactions depends on the Smart Contrac that you have on the Peers, and the Endorsement Policy that you have defined. Then, each Peer sends the validated transactions to the Ordering Service.
The Blocks are created by the Ordering Service, so the blocks will be equal to both peers.
The solution to that issue would be to create an Ordering Service where the orderers are located in additional and independent 3rd party.
Nowadys, the Ordering Services gives you the chance to choose among different Services: two different are developed, a third one will be ready soon. More info about it, here.
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.