I work in a company where in order to send staff to the field, employees have to comply with a certification that expires each 4 years, which probably employees did in their previous job, but the previous job just provided a letter that could be falsified, also, others companies don't spend time and resources to share their databases advocating security for the sensitiveness of data (names, nationality, id, company (including governments), date completion), centralization is a risk they don't want to take. As this is a training that is the same, and conducted everywhere that produces a contract between the company and the person, that expires in 4 years, but the person would like to be able to certify itself with the other companies, I was wondering if there is such implementation in the blockchain world, where writers, public ones, with no interest in 3rd parties, but in consensus due to the training nature, are willing to write/read the transaction on a secure manner providing a "self-service" among producers and consumers.
Assuming the other companies want to participate in the scheme, it is perfectly plausible to use some blockchain solution. You might want to use Hyperledger Fabric to create a privately permissioned blockchain network between the relevant stakeholders.
However don't get sucked into the blockchain hype, evaluate objectively whether the rest of the business processes also fit in the paradigm. Can certifications be revoked? Are there regulations on what data you can store on the employees and rights they have to get their data erased?
There might be many other simpler solutions that achieve the same thing. If the company or training provider just has a private key that signs certificates (PDF?) it might already be enough to solve your letter falsification issue.
Maybe each company could host its list of certified trained people on its own repository which could be queried, such that the list of certified people is maintained up to date (and any revocations can also be handled online), would probably achieve exactly the same result. Just like most other blockchain use-cases, there is a simpler solution that achieves the same thing, and is probably more flexible to fit the rest of the business processes.
Finally, before engaging in too much effort, make sure the other third parties are on-board. Do they really want to share the list of people they trained with competitors? If there is a likelihood they will not play along the project will probably be DOA. Case in point what happened here:
https://www.coindesk.com/ibm-blockchain-maersk-shipping-struggling/
Related
I am just starting out as a blockchain developer and I want a blockchain service except Ethereum (already implemented) to store a hash (SHA256 and ISCC hashes) of a document in a blockchain so that it can verify its validity and is tamper proof. There is already a UI to generate hashes and I need a blockchain to store the hashes
My need is:
I want to have a blockchain service with low transaction cost and high transaction speed. Also, I want that the hashes be stored in the blockchain for a long period of time (5 years). Which blockchain would be best fit for this usecase?
To answer your question, you need to understand who will be the users of your project. Accordingly, it is necessary to use the public or private blockchain further. For public blockchains, the choice is quite small - of those that will live for 5 years, these are most likely Bitcoin and Ethereum. For private blockchains, the choice is much wider: Ethereum / Quorum, Hyper Ledger Fabic, Corda and many others. Each of them has its own complexity of deployment, development and support.
But the very first question - why do you need blockchain? To store hashes of files, you can use IPFS or cloud storages, certifying them with a digital signature of a certain "notary" participant or, for example, the owner of the file. In terms of performance and low cost, these are the most efficient solutions.
I want to have a blockchain service with low transaction cost and high transaction speed.
Everyone wants this, so you are not along with your requirements.
Also, I want that the hashes be stored in the blockchain for a long period of time (5 years). Which blockchain would be best fit for this usecase?
Currently all blockchains assume the state is stored permanently - or to the end of the world or until nobody runs nodes anymore. Whichever comes first. There is a risk of dead chain, so whatever you pick might not be around after five years. However this is a business discussion, so it is hard to answer to this one on StackOverflow.
For your use case, it does sound you do not need a blockchain at all, but just having a public data storage that is prepaid for up to five years.
You can use Emercoin NVS for upload your hashes. Service emernotar.io already does so. Also, you can use File Validator service, all scripts are open source and available on Github.
I'm documenting in this blockchain world. Basically I would like to make some web application in which a user decides to make a donation, and would like to see who made the donation and to which entity. I have several doubts, the first one:
1-Is it possible to use blockchain using javascript? (can smartcontracts be done in javascript?)
2- If the donation is made using blockchain, is it necessary to use a cryptocurrency? or you can use real money and make the transaction (using some means like paypal)
3- Can real money be transferred by some means such as paypal using blockchain?
Thank you very much, your answers will document me much more
Is it possible to use blockchain using javascript? (can smartcontracts be done in javascript?)
Every blockchain has a SDK, the part of the software which lets you
interact with the real blockchain( A decentralise ledger). There
are generally two parts in the Blockchain , One is client and one
is processor.
As you must have guessed, Client is the one who sends the transaction,
This transaction must satisfy certain rules in order to be accepted by
the transaction processor. If the transaction gets validated by
transaction processor, The transaction will be added to the block alongwith
other transactions and this block will then be added to the blockchain.
Copied to all other nodes (Forks are a different story)
Generally Most blockchains lets you interact with the blockchain through
ABCI which is just an interface to convert your transaction into
a format understandable by the blockchain processor.
Some blockchains has their fixed transaction processing logic like Ethereum for
security and some lets you write your own transaction processing logic like
Sawtooth, Fabric etc.
Permissioned and some public blockchains like Hyperledger projects and
cosmos SDK lets you write your own application layer logic for Blockchain,
So yes, You can write those transactions in Javascript or any other programming
language, as long as it satisfies the interface.
Public blockchain deals with tokens having real worth. Their transaction logic
is already fixed, but some of them does provide javascript API's like NEO
(Not sure about that)
2- If the donation is made using blockchain, is it necessary to use a cryptocurrency? or you can use real money and make the transaction (using some means like paypal)
You can do that and put the donation receipt on Blockchain linked with
real identities of people. This way if anybody wants to check who pays
how much donation, They can query blockchain for the user address.
3- Can real money be transferred by some means such as paypal using blockchain?
This can also be done, but this will involve using a crypt exchange,
centralised or decentralise. You can convert the real money into crypto
of your choice at one end and vice versa at the other hand.
Note: This is based on my limited knowledge of Cryptocurrencies. Please consult more people or any professional company before acting on this advice.
I don't think any protocols offer the possibility to implement their smart contracts in Java Script, but you can build a translator between the two languages which could potentially benefit others in the open source community.
So you want have some engineers do some work for you, in this case build an web application. There are several ways you can get this done, here are some ideas:
a) issue tokens which pays profits based on the success of your new business, you might be able to do this on a protocol that is not tied to any specific crypto or fiat currency.
The users can use an exchange to convert your tokens to their favorite one.
b) approach a private equity or VC fund and get them to pay for it.
c) forget about blockchain, and just pay for the project to your favorite engineers.
I recently learned, traditionally, interbank payment systems need following features to carry out tasks:
need a central bank to prevent parties involved from going bust.
need a clearing house to perform netting algorithms to minimise liquidity requirement.
If we use corda to implement a similar payment system:
do we still need central banks and clearing houses appearing in the networks as independent nodes?
If so, what do they do?
Do they serve as notary nodes or something else?
What relationships do they have with commercial banks?
Why this kind of corda-based design is better than traditional interbank payment system?
Corda has been used to develop a real-time gross settlement pilot in association with the Monetary Authority of Singapore. See the report here: http://www.mas.gov.sg/~/media/ProjectUbin/Project%20Ubin%20Phase%202%20Reimagining%20RTGS.pdf and the source code here: https://github.com/project-ubin/ubin-corda.
Using Corda removes the need for clearing houses. Netting and delivery-versus-payment/atomic asset swaps can be achieved without the need for a centralised party. Corda also removes the need for reconciliation, which happens automatically via the platform.
More importantly, Corda is driving towards a vision of global interoperability. See
https://medium.com/corda/universal-interoperability-why-enterprise-blockchain-applications-should-be-deployed-to-shared-3d4daff97754. In this vision, assets are not trapped in silos, and can move freely across the network. For example:
BankNode receives cash via the interbank payment system
BankNode lends this money to SupplierNode in exchange for an obligation
SupplierNode uses this money to purchase goods from FactoryNode
FactoryNode uses the money to pay the suppliers of its raw materials
And so on, and so on...
Coordinating things using a clearing house remains possible when looking at a single area like interbank payments. However, as the network grows to support many different business use-cases - supply chain, lending, assets, payments... - it becomes increasingly difficult to find a coordinating party that can be trusted by all parties, across industries and regions. Corda removes the need to identify such a coordinating party.
In this vision, central banks are likely to continue to exist as trusted issuers of fiat currency.
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/
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.