-
Notifications
You must be signed in to change notification settings - Fork 3
Blockchain and contracts
A blockhain is a decentralised way of keeping records. According to their website : "Ethereum is a decentralized platform that runs smart contracts". Functionally it's a ledger (blockchain) that can be used to run code written in solidity, which is a turing complete language.
It's especially interesting for this project as it would give the possibility for anyone to verify automatically whether a badge is valid. This would be interesting for multiple reasons, first one being the simplification of the verification by creating the possibility of automating the whole process, second one is giving the possibility of verification of badges even if the issuer do not exist anymore and lastly decentralising the whole process.
There are two contracts. One is a general contract named badgeHash that was built to be used for any hash with a length under 1024 (to ensure that there isn't an heavy gaz cost due to a mistake somewhere). This hash save the length of the string too, so it can be checked (as the return of a varied length object from another contract is not supported yet).
The second is called sha256badge. It take 256 bytes (as for example the result of a SHA256 hashing) and save them in the blockchain. It is a better implementation than the previous one as it's much less costly and there is less chance for someone to make an error while developing for it.
Both contract are using a mapping which mean that there is no need to verify the receiver, only the sender matter.
A blockchain (like ethereum's) has many advantage for the verification of badge but it also has multiples issues.
First one being that each badge sent necessities gaz, which cost money and require the user to have an ethereum account and also to keep that account furnished (which is against the main principle behind this project which was to make badges easier of use for a lambda person).
Second being that ethereum is a very recent technology that is still in development. This mean that there is no way of knowing of whether it would even exist in ten years of time, or what it would look like. Also, as it's a very recent technology there is not a lot of documentation available on Internet and thus there is not many programmers that have more than basic knowledge of the subject, which make future development harder.
Somewhat hinging on those problems is the problem of the non stability of ethereum. One year ago, 1 ETH cost 12.83$. Right now, 1 ETH cost 217.26$. A multiplication by a factor of 17. While it's unlikely this growth will continue exponentially, the possibility exist and need not to be dismissed. Most importantly, this growth can very well be reversed, which would make the miners of ethereum go toward greener pastures (as mining ETH wouldn't be lucrative enough anymore), thereby making more easy for hackers to do a 50%+1 attack (which is a type of attack unique to blockchains, that depend on the hackers having access to more than 50% of the combined computing power of the miners).
Lastly, there is the problem of verifying the identities of the people using the blockchain. Because verifying that one account sent a badge to someone is not enough to verify that one person got this badge from this other person. For that there need to be a link between the person described in the badge and the “real” one. This is an issue that is common at almost any computer based verification, and that, for the moment at least, can’t be solved by computers.
There exist many alternatives to using a blockchains for automating the verification of badges.
The first one and the simplest would be to make an open source website with a database that store hashes. This way any organization wanting to give badge and not bother with manual verification could set up their own websites and verify which badge they sent (or which badges people they accept as issuer sent). It has the advantage of not letting anyone see that badges and which hashes have been issued and being very scalable.
The second on is using Littleton signatures. This has been already partly implemented (if not linked yet). The problem of this method is that it require the user to save their keys and publish their public key. However, his require more knowledge than can be expected of the layman.
http://remix.ethereum.org/#version=soljson-v0.4.13+commit.fb4cb1a.js https://www.coingecko.com/en/price_charts/ethereum/usd Consulted the 25/07/2017 https://steemit.com/crypto-news/@eeks/ethereum-classic-etc-valuation-usd0-71-price-65-lower-fixed-version-updates