Taking the following service description:
X is a platform matching buyers and sellers.
Buyers can join the platform by creating a buyer account and browse seller shops, buy, manage their account, ..., on the Buyers client application.
Sellers can join the platform by creating a seller account and manage their shops and orders, ..., on the Buyers client application.
I am still confuse about the right approach to adopt.
Here I represented the organization X (the platform). I assume that a buyer is not considered as an organization but rather a user of X. So every time a buyer create an account, I register a user under X, save email and password on an external database and link this entry to a user in X's wallet.
A seller can be considered as an organization (at least to me but happy to debate on that). So every time a seller create an account, I have to create an add a new organization to the existing network. They will however share the same "Seller application", also using a email/password approach.
In most of the sample under the Hyperledger Fabric repo, there is like 3-4 organizations at the start of the network and it is quite painful to add one more to an existing network. In my case, I could end up with 1 million organization or an infinite if the service is a success. Can this scale?
Is it the correct approach for this kind of use case? Any feedback or resource related to this use case is welcome.
This doesn't look like a valid use of hyper-ledger fabric. The blockchain is optimized to store transactional information. It isn't a regular DB, if you try, for instance, to store "user profiles" you will have a hard time trying so. For instance, each member for the blockchain network (again, hyper-ledger fabric) is meant to keep a copy of the ledger. Thus, everyone would get access to all user profiles. You can play around with PDC (private data), or as you mention, having virtually infinite users created on a single organization, but that isn't really how it's supposed to be used..
So, again, hyper-ledger fabric is meant to store transactional information (ledger relates to transaction). I think whatever strategy you try to implement for your use case, you should keep buyer/seller profiles/information off chain, and use the ledger only for transactional information that members of the network can see. In this scenario Fabric would server as an audit trail system, adding trust to each operation between buyers/sellers.
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 am very new to quorum programming. I already made some Smart Contracts with solidity on ethereum and made some dapps with Truffle, React and Metamask.
Now I did this Quorum Tutorial: https://truffleframework.com/tutorials/building-dapps-for-quorum-private-enterprise-blockchains
Before I get to the problem I have, I tell you what I am trying to do:
Right now we have a database in our school, where the teacher can save the marks of the students, and the students can log in and see the marks they have. I'm trying to make a prototype, where this data is stored on a private blockchain like quorum.
So what I already did is a react front end for the prototype and I want that teachers can log in, save marks for a student and then the students can log in and see their marks. This means that students and teachers all need a login.
The Problems I face:
How can I set up a local productive quorum node?
For ethereum and ganache, you can use metamask and then use the
metamask account in the react front-end to make transactions. How
does it look like with quorum?
How can I make a login? Or does the teacher and student need to know
a private key for their account?
As you can see, Im very new in this world and I need to learn a bit more about the concept.
Thank you for your help
How can I set up a local productive quorum node?
Something like Quourum Maker may assist you in being able to quickly bootstrap a Quorum network without having to go through tedious manual configuration. The Quorum documentation is also full of tutorials that can guide you through this process.
For ethereum and ganache, you can use metamask and then use the metamask account in the react front-end to make transactions. How does it look like with quorum?
You could utilize something akin to ethereumjs-wallet to create wallets in-code and send the transactions via the Quorum web3.js library. You would need to then map these wallets to users in an off-chain database which leads into your next question.
How can I make a login? Or does the teacher and student need to know a private key for their account?
You can handle authentication in your web application via an IDP in which students and faculty already have existing credentials with if you have the appropriate access to do so. Otherwise, you could utilize SSO with well-known IDPs via something akin to Auth0.
Your flow would essentially involve first having the user authenticate, then tying their identity to a generated Ethereum wallet upon their first authentication and persisting these tied identities to an off-chain database. Subsequent authentications would pull the persisted wallet information from the off-chain database and use that for transaction signing. Other considerations would involve utilizing appropriate key management services as well as utilizing an HSM for secure transaction signing.
I could have given you the steps but on a second thought, I think its a good idea to start using something simpler like https://github.com/ssbc/ssb-db and then, come back to Ethereum.
I am currently learning ETH blockchain based DApp development. I want to ask that, if we are developing an eVoting application based on blockchain, then how can we ensure that each citizen is voting only once and votes are calculated properly to avoid duplicate votes?
Thanks
Identity is a very difficult thing to do on the blockchain and is the subject of very active research by many large and small entities.
With this said, the way to limit users to one vote each on the Ethereum blockchain is to limit each public address to one vote each. Your smart contract can check if the user has already voted, and can deny the user a second vote. This does not stop users from simply creating a second account and voting again.
The most effective way to do this given technological limitations is to simply perform the identity check off-chain. You can implement a Know Your Customer (KYC) system on your site and assign each user to a single address. Provided the system is robust, it should be extremely difficult for people to create multiple identities.
I have a web site which sells certain information for its users for a fixed cost.
I want to go ICO with my business and trying to change my operating model so it can leverage blockchain technology.
However I want to make sure that auction participants are in some way abstracted from their Ethereum wallet and budding in points (they will pay later if action is actually won. i.e. eBay model) without knowing that they are actually using blockchain behind the scenes. Once bidding is complete, ICO investors will automatically get their share distributed to them, and winning bidder will receive their info upon payment (in most cases real money which we will convert to ETH and mark status as paid in solidity contract)
Is there any solution for that problem, can i create wallets on the fly for the bidders accounts? Since my site is always a seller, is there a way to set auctions automatically (interact with my contract from my lets say java backed etc?)
Is there any work around/ suggestions?
Thank You
You can create wallets on the fly for your customers. That's perfectly doable. But as you create the wallets, customers can't trust those wallets you have their private keys, so they should withdraw the funds immediately to their wallets. This took us to step 0: Wallet creation. So either way, your customers have to create a wallet for themselves, for security reasons.
Consider the following micro services for an online store project:
Users Service keeps account data about the store's users (including first name, last name, email address, etc')
Purchase Service keeps track of details about user's purchases.
Each service provides a UI for viewing and managing it's relevant entities.
The Purchase Service index page lists purchases. Each purchase item should have the following fields:
id, full name of purchasing user, purchased item title and price.
Furthermore, as part of the index page, I'd like to have a search box to let the store manager search purchases by purchasing user name.
It is not clear to me how to get back data which the Purchase Service does not hold - for example: a user's full name.
The problem gets worse when trying to do more complicated things like search purchases by purchasing user name.
I figured that I can obviously solve this by syncing users between the two services by broadcasting some sort of event on user creation (and saving only the relevant user properties on the Purchase Service end). That's far from ideal in my perspective. How do you deal with this when you have millions of users? would you create millions of records in each service which consumes users data?
Another obvious option is exposing an API at the Users Service end which brings back user details based on given ids. That means that every page load in the Purchase Service, I'll have to make a call to the Users Service in order to get the right user names. Not ideal, but I can live with it.
What about implementing a purchase search based on user name? Well I can always expose another API endpoint at the Users Service end which receives the query term, perform a text search over user names in the Users Service, and then return all user details which match the criteria. At the Purchase Service, map the relevant ids back to the right names and show them in the page. This approach is not ideal either.
Am I missing something? Is there another approach for implementing the above? Maybe the fact that I'm facing this issue is sort of a code smell? would love to hear other solutions.
This seems to be a very common and central question when moving into microservices. I wish there was a good answer for that :-)
About the suggested pattern already mentioned here, I would use the term Data Denormalization rather than Polyglot Persistence, as it doesn't necessarily needs to be in different persistence technologies. The point is that each service handles its own data. And yes, you have data duplication and you usually need some kind of event bus to share data across services.
There's another option, which is a sort of a take on the first - making the search itself as a separate service.
So in your example, you have the User service for managing users. The Purchases services manages purchases. Each handles its own data and only the data it needs (so, for instance, the Purchases service doesn't really need the user name, only the ID). And you have a third service - the Search Service - that consumes data produced by other services, and creates a search "view" from the combined data.
It's totally fine to keep appropriate data in different databases, it's called Polyglot Persistence. Yes, you would like to keep user data and data about purchases separately and use message queue for sync. Millions of users seems fine to me, it's scalability, not design issue ;-)
In case of search - you probably want to search more than just username, right? So, if you use message queue to update data between services you can also easily route this data to ElasticSearch, for example. And from ElasticSearch perspective it doesn't really matter what field to index - username or product title.
I usually use both approaches. Sometimes i have another service which is sitting on top on x other services and combines the data. I don't really like this approach because it is causing dependencies and coupling between services. So in general, within my last projects we tried to stick to polyglot persistence.
Also think about, if you need to have x sub http requests for combining data in some kind of middleware service, it will lead you to higher latency. We always try to cut down the amount of requests for one task and handle everything what is possible through asynchronous queues. ( especially data sync )
If you conceptualize modules as the owners and controllers of the data they work on, then your model must also communicate that data out of that module to others. In contrast, the modules in a manufacturing process have the access to change data without possessing and controlling it.
Microservices is an architecture for distributed processing, like most code, where modules pass the data around to work on it. From classic articles by Harvard Business Review and McKinsey on the subject of owning members of a supply chain, I identified complexities arising from this model and wrote an article teaching programmers what you need to know: http://www.powersemantics.com/p.html
Manufacturing is an architecture for integrated processing, where modules work on the data without passing it around from point to point. This can be accomplished by having modules configured to access the same memory, files or database tables. My architecture shows how to accomplish this on memory via reference properties.
When you consider "exposing an API at the Users Service end which brings back user details based on given ids", you need to be aware that creates what HBR calls "irreversible" complexity, which I've dubbed centralization complexity. Don't build A->B (distributed) systems, because you can't decentralize them later after failing to separate requirements. Requirements in production processes represent user instructions, and centralized modules only enable you to change the wrong users' processes. In other words, centralized modules don't document user groups or distinguish them from derived-product-users.