I am just started learning how to build the fabric network, but it is still blurry to me how in the real world if we want to add a new node/organization.
I want to build a network of parking providers and an integrator. each parking provider will have its own node. then a new parking provider decides to join the network, are the parking provider set up its own node and give the node information to the integrator (network admin) so that the admin can add its node to the network?
If you are new to developing networks, you should follow the Hyperledger Fabric tutroial for Adding a new Org. Try to get this to work first just by running the scripts. The next learning step is to do the same action using command line statements instead. This will give you a better understanding of how it all hangs together. If you are comfortable at that stage, the next thing is to be able to add the same additional organisation but now introduce a Certificate Authority. This will increase your knowledge of the docker scripts and configuration files. The built in shell scripts do not use a CA for the third Org to be added to the "test-network".
If all of this seems overwhelming, then you are off to a good start, because it is. Understand how the network was built before you try to add a new Org. You will better understand the steps required to add more organisations once you do.
In the real world you'll be working through specific use cases and trying to figure out if a blockchain is what you need. Typically a good way to look at it is to identify the business objects of interest (-> these go into world state), then consider how transactions shape them (-> these go into the channel) and from there consider what logic you need (-> i.e., some sort of "state machine" in your smart contract that is deployed as chaincode) and how this logic is to be invoked by peers (-> this is where your client app comes into play).
If that all works you'll be in a position to judge if a blockchain architecture is what you need and want.
Now to your details...
Any node must belong to an organisation so my first guess is that you have one organisation per parking provider and that each parking provider may therefore have one or more nodes (recall node=peer,client,ordering service).
Next I'm a bit unsure what role of the integrator is (beyond network configuration?). For example, you might want to give parking providers autonomy to join or you might want to impose a central authority for organisational membership? Also you might want to have the integrator do things that the parking providers are less enthusastic about (e.g., ordering service?).
I'll guess you'll figure those details out
Related
So I am new to blockchain. In fact, I am actually doing a one-year diploma for it. I found out it's incredibly hard to find accurate information online regarding blockchain. It's either a chunky mess or completely irrelevant. Right now my team's project is to work on a real-life situation where blockchain could be implemented and we chose blockchain for student credentials. We went with a Hybrid blockchain where certain personal information will be private and other stuff like credentials will be public so that educational institutes can validate them. We are supposed to be working with Hyperledger Fabric for the assignment, but we are stuck deciding whether we should be using ERC-721 Tokens or smart contracts to assign every student a unique digital asset. I am posting this here to see if I can get some help.
p.s dont mind if my concepts are completely off because its only been like a week or 2 since my classes started.
In Russia, finance academy "Active" already uses Emercoin blockchain for this purpose for years. You can use Google Translate and read the interview article.
I think, if you contact them, they will share with you their solutions and source code.
You can implement your use cases with Hyperledger Indy blockchain framework. Hyperledger Indy will suit your use cases as this blockchain framework is used to manage identities.
You can visit Indy Walkthrough demo where you can find tutorial with code based on your use cases.
You can also check the following demo:
https://www.youtube.com/watch?v=9WZxlrGMA3s
I am using a Hyperledger Fabric Blockchain.
My blockchain is "private", which means only people we accept can participate.
Right now, the blockchain is open to Internet. Is it safe ?
Should I put my Blockchain behind an API that would be in charge of Read / Write operations ?
From the "data certification" point of view, less steps between data and blockchain, the better.
Does it make sense in a security point of view ?
I don't get what you mean by blockchain being opened to internet.
If you are referring to the data structure of blocks forming a chain, it's just some files stored in peer component. If you want to discuss about it being opened, I'd rather see it as a peer component being opened to the internet.
If you manage to protect the peer component from illegal access, the only legal access Fabric provides you is through using correctly authorized certificate, so from that point on, I wouldn't worry that much.
Putting API middleware in front of the blockchain, however will provide easier interface for other users. From realistic implementation point of view, those interface will be required to some point, so it should better be protected from other security threats.
What you may want to do is to create a "standard" API for your network. This would be an app which can request for and store crypto from the CA and provides some sort of authentication mechanism to allow authorized users to then use that crypto to make requests to the network.
When you begin onboarding users to your network, you need to give them the option of using your standard API or making their own. This gives them the convenience to get started quickly by using a pre-built solution with the freedom to build their own interface into the network if they would like to.
Right now, the blockchain is open to Internet. Is it safe ?
First of all, Blockchain is secure because of its design. Blockchains stores data using certain rules that are extremely difficult for attackers to manipulate. As the numbers of block grows, it will be harder for attacker to manipulate the old block.
However, although we have a super secure blockchain system, we can't control the security of each user account or third party system.
That's why most of the security breaches in public blockchain are happening on the third party system or because of human error (not inside the blockchain).
Should I put my Blockchain behind an API that would be in charge of
Read / Write operations ?
API can be seen as a "bridge" between blockchain and us. Of course, we need this bridge to read / write Transactions to blockchain. It doesn't matter what bridge are you using, as long you can ensure the security of your bridge design.
From the "data certification" point of view, less steps between data
and blockchain, the better. Does it make sense in a security point of
view ?
One of the important aspect private blockchain is about limiting who can access into a blockchain. By limiting the user interaction, we can reduce the potential of security breach. So, the risk of having security breach can be reduced.
I know the concept of building a simple P2P network without any server. My problems is with securing the network. The network should have some administrative nodes. So there are two kinds of nodes:
Nodes with privileges
Nodes without privileges
The first question is: Can I assign some nodes more rights than others, like the privileges to send a broadcast message?
How can I secure the network of modified nodes that are trying to get privileges?
I'm really interested in answers and resources than can help me. It is important to me to understand this, and I'm happy to add further information if anything is unclear.
You seem lost, and I used to do research in this area, so I'll take a shot. I feel this question is borderline off-topic, but I tend to error toward leaving things open.
See the P2P networks Chord, CAN, Tapestry, and Pastry for examples of P2P networks as well as psuedo-code. These works are all based off distributed hash tables (DHTs) and have been around for over 10 years now. Many of them have open source implementations you can use.
As for "privileged nodes", your question contradicts itself. You want a P2P network, but you also want nodes with more rights than others. By definition, your network is no longer P2P because peers are no longer equally privileged.
Your question points to trust within P2P networks - a problem that academics have focused on since the introduction of (DHTs). I feel that no satisfactory answer has been found yet that solves all problems in all cases. Here are a few approaches which will help you:
(1) Bitcoin addresses malicious users by forcing all users within their network do perform computationally intensive work. For any member to forge bitcoins that would need more computational power than everyone to prove they had done more work than everyone else.
(2) Give privileges based on reputation. You can calculate reputation in any number of ways. One simple example - for each transaction in your system (file sent, database look up, piece of work done), the requester sends a signed acknowledgement (using private/public keys) to the sender. Each peer can then present the accumulation of their signed acknowledgements to any other peer. Any peer who has accumulated N acknowledgements (you determine N) has more privileges.
(3) Own a central server that hands out privileges. This one is the simplest and you get to determine what trust means for you. You're handing it out.
That's the skinny version - good luck.
I'm guessing that the administrative nodes are different from normal nodes by being able to tell other nodes what to do (and the regular nodes should obey).
You have to give the admin nodes some kind of way to prove themselves that can be verified by other nodes but not forged by them (like a policeman's ID). The Most standard way I can think of is by using TLS certificates.
In (very) short, you create couples of files called key and certificate. The key is secret and belongs to one identity, and the certificate is public.
You create a CA certificate, and distribute it to all of your nodes.
Using that CA, you create "administrative node" certificates, one for each administrative node.
When issuing a command, an administrative node presents its certificate to the "regular" node. The regular node, using the CA certificate you provided beforehand, can make sure the administrative node is genuine (because the certificate was actually signed by the CA), and it's OK to do as it asks.
Pros:
TLS/SSL is used by many other products to create a secure tunnel, preventing "man in the
middle" attacks and
impersonations
There are ready-to-use libraries and sample projects for TLS/SSL in practically every language, from .net to C.
There are revocation lists, to "cancel" certificates that have been stolen (although you'll have to find a way to distribute these)
Certificate verification is offline - a node needs no external resources (except for the CA certificate) for verification
Cons:
Since SSL/TLS is a widely-used system, there are many tools to exploit misconfigured / old clients / servers
There are some exploits found in such libraries (e.g. "heartbleed"), so you might need to patch your software a lot.
This solution still requires some serious coding, but it's usually better to rely on an existing and proven system than to go around inventing your own.
I am using Flash Media Server.
I am confused over various IDs
I am the nearID? And, the person on the other end is farID?
What is a nearNonce ID?
I found a high level architecture explanation that beautifully explained how P2P works overall.
Are there any more articles with detailed explanation of how all pieces fit together in the puzzle?
Finally, for peers to communicate they need to exchange peerIDs. Would using a remote shared object perform this task well or would suggest using some other kind of web service like XMPP?
Apologies for the many questions.
FMS programming can get very confusing. To tackle you last question, typically your peers are introduced via the FMS itself - in Server Side AS. One way to do this is to have your peers connect to a NetGroup, in which case they can discover other peers connected to the same group. You can also manually introduce 2 peers in the SSAS code.
One hard lesson I learned about NetGroups is that simply being connected to a group does not mean that you will receive notification when others join the same group. You only get notified when you gain a new neighbor, which is a direct connection within the group, vs a new non-neighbor peer in the group, which is an indirect connection through other peers. If you want to know when a peer joins a group that peer should announce themselves via a group broadcast.
I'm still learning this stuff, so take this all with a grain of salt :)
While the are many social networks in the wild, most rely on data stored on a central site owned by a third party.
I'd like to build a solution, where data remains local on member's systems. Think of the project as an address book, which automagically updates contact's data as soon a a contact changes its coordinates. This base idea might get extended later on...
Updates will be transferred using public/private key cryptography using a central host. The sole role of the host is to be a store and forward intermediate. Private keys remain private on each member's system.
If two client are both online and a p2p connection could be established, the clients could transfer data telegrams without the central host.
Thus, sender and receiver will be the only parties which are able create authentic messages.
Questions:
Do exist certain protocols which I should adopt?
Are there any security concerns I should keep in mind?
Do exist certain services which should be integrated or used somehow?
More technically:
Use e.g. Amazon or Google provided services?
Or better use a raw web-server? If yes: Why?
Which algorithm and key length should be used?
UPDATE-1
I googled my own question title and found this academic project developed 2008/09: http://www.lifesocial.org/.
The solution you are describing sounds remarkably like email, with encrypted messages as the payload, and an application rather than a human being creating the messages.
It doesn't really sound like "p2p" - in most P2P protocols, the only requirement for central servers is discovery - you're using store & forward.
As a quick proof of concept, I'd set up an email server, and build an application that sends emails to addresses registered on that server, encrypted using PGP - the tooling and libraries are available, so you should be able to get that up and running in days, rather than weeks. In my experience, building a throw-away PoC for this kind of question is a great way of sifting out the nugget of my idea.
The second issue is that the nature of a social network is that it's a network. Your design may require you to store more than the data of the two direct contacts - you may also have to store their friends, or at least the public interactions those friends have had.
This may not be part of your plan, but if it is, you need to think it through early on - you may end up having to transmit the entire social graph to each participant for local storage, which creates a scalability problem....
The paper about Safebook might be interesting for you.
Also you could take a look at other distributed OSN and see what they are doing.
None of the federated networks mentioned on http://en.wikipedia.org/wiki/Distributed_social_network is actually distributed. What Stefan intends to do is indeed new and was only explored by some proprietary folks.
I've been thinking about the same concept for the last two years. I've finally decided to give it a try using Python.
I've spent the better part of last night and this morning writing a sockets communication script & server. I also plan to remove the central server from the equation as it's just plain cumbersome and there's no point to it when all the members could keep copies of their friend's keys.
Each profile could be accessed via a hashed string of someone's public key. My social network relies on nodes and pods. Pods are computers which have their ports open to the network. They help with relaying traffic as most firewalls block incoming socket requests. Nodes store information and share it with other nodes. Each node will get a directory of active pods which may be used to relay their traffic.
The PeerSoN project looks like something you might be interested in: http://www.peerson.net/index.shtml
They have done a lot of research and the papers are available on their site.
Some thoughts about it:
protocols to use: you could think exactly on P2P programs and their design
security concerns: privacy. Take a great care to not open doors: a whole system can get compromised 'cause you have opened some door.
services: you could integrate with the regular social networks through their APIs
People will have to install a program in their computers and remeber to open it everytime, like any P2P client. Leaving everything on a web-server has a smaller footprint / necessity of user action.
Somehow you'll need a centralized server to manage the searches. You can't just broadcast the internet to find friends. Or you'll have to rely uppon email requests to add somenone, and to do that you'll need to know the email in advance.
The fewer friends /contacts use your program, the fewer ones will want to use it, since it won't have contact information available.
I see that your server will be a store and forward, so the update problem is solved.