These are some of the key considerations when evaluating an ICO:
What is the token trying to achieve/solve/disrupt
How many of the total tokens being issued are held by the ICO issuer?
Which individuals are part of the ICO issue core team? What are their backgrounds, what is their track record in this space
If there is a GitHub page, review the various repositories and see how many people are supporting it, and what percentage are active, because you could have one hundred people listed, and only five are active, not a good sign. How often are changes being committed?
How long does the ICO run for?
What does the ICO issuer plan to do with the capital raised?
If the ICO has already been issued, check http://coincap.io for its details.
See what community is saying about this ICO, sites like:
https://www.smithandcrown.com/
http://reddit.com
Team sites on Telegram
Team sites on Discord
Team sites on Slack
Blockchains suffer from scaling issues. This is due to the fact that every transaction has to be propagated to all the nodes in the network and after propagation is complete the mining activity to create a block and provide a confirmation. In bitcoin blockchain a confirmation can take about ten minutes. When it comes to the security of a blockchain the number of nodes is directly related to the security of the blockchain, more nodes mean better security. Whereas the performance is indirectly proportional whereby as the number of nodes increases the blockchain starts to slow down as the transactions need to be propagated to more nodes.
Transactions Per Second (TPS) for some blockchains are:
Bitcoin Blockchain processes 7 TPS
Ethereum processes 13TPS
Ripple processes 1500 TPS
Visa processes 1700 TPS, if required the system can process up to 56000 TPS
Scaling Solutions
Besides sharding, some of the scaling solutions, called layer two solutions that I will be discussing are:
Plasma for Ethereum
Raiden for Ethereum
Lightning for Bitcoin and Litecoin
Plasma
Plasma addresses the scaling problem by providing a framework that allows implementation of nested chains.
“Plasma is a proposed framework for incentivized and enforced execution of smart contracts which is scalable to a significant amount of state updates per second (potentially billions) enabling the blockchain to be able to represent a significant amount of decentralized financial applications worldwide.
These smart contracts are incentivized to continue operation autonomously via network transaction fees, which is ultimately reliant upon the underlying blockchain (e.g. Ethereum) to enforce transactional state transitions.”
This is how you would deploy a Plasma chain:
A smart contract is deployed on Ethereum main net that serves as the “root” of the child chain. It contains the basic “state-transition rules” of the child chain, records hashes, and serves as bridge that lets users move assets between the child chain and Ethereum main net.
A child chain is created that has its own consensus algorithm such as PoA, PoS, or other.
Deploy Child chain related contracts to the child chain
As the child chain produces blocks, they are committed to the root contract created in #1 above.
The root contract commits the updates to mainnet.
Raiden
Raiden is a lightning implementation for Ethereum, and next I will talk about Lightning.
“The Raiden Network is an off-chain scaling solution for performing ERC20-compliant token transfers on the Ethereum blockchain. It is Ethereum’s version of Bitcoin’s Lightning Network, enabling near-instant, low-fee, scalable, and privacy-preserving payments.”
Lightning
Implements Smart contracts, using three technologies:
Multi Signatures.
Check Lock time and Check sequence verify, relative time from previous transaction.
Hash lock time contracts, forward a promise that can be unlocked by a secret.
State channels are setup between parties. The party initiating the channel has to deposit bitcoin in escrow, this ensures that the other party will receive the funds once the channel is closed. The amount deposited establishes the maximum value that can be transacted within the channel.
Final transaction is written to the bitcoin blockchain after the state channel has been closed.
You have to stay online all time to ensure other party does not close the channel on you
In case you get cheated, you have 8 hours to send a competing transaction
Scaling at every layer
Lightning applications (lApps) vs dApps
You can deploy a lightning node. BOLT(Basis of Lightning Technology) is an interoperability standard. Currently there are three BOLT compliant technologies to implement lightning.
LND from Lightning Labs
C-Lightning from Blockstream
Éclair from ACINQ
Conclusion
All blockchains throughput was tested in Q4 2017 when they got bogged down by the number of transactions and the transaction fees soared. Lightning went live Q1 2018 while the other two are still in development.
Smart cities, AI, Blockchain, are the new buzzwords these days. In this post will be talking a bit about these technologies and their relationship to blockchain.I have been to a few meetups at The Blockchain Hub at York University in Toronto. The Blockchain Hub folks seem to be contributing a lot to the blockchain action in the Toronto area. Of the meetups worth mentioning following come to my mind:
Smartcities, IoT, and Blockchain
AI and Blockchain
Hadera, a public version of the Hashgraph
Smart cities, IoT, and Blockchain
I totally understand smart cities and the use of internet of things, but the whole proposition becomes questionable where people throw the word blockchain in the mix. There were claims of money saving and energy efficiency, what escapes me is what does blockchain have to do with all this. It would have made sense if the presenter had spoken about a specific blockchain use case, apparently not. The way I see it is that what makes a city or a home smart is the deployment of various sensors and control systems performing actions in unison. IoT comes into play where all the control systems and sensors are connected together over IP. This central hub processes all the information flowing in from the IoT devices, and signals IoT devices to perform certain activities.
The only use case I see of the blockchain is when monetizing is involved. IoT devices effectively could be charging other IoT devices and control systems for providing them the data they have collected. For this collection, sharing, and charging for data a very fast blockchain technology has to be utilized. The only blockchain that is capable of accomplishing such speed is IOTA Tangle, which is designed for this very purpose. There is nothing stopping anyone from using existing database technologies such as MySQL, Oracle, etc. It really depends on the architecture and requirements that the platform needs to address.
AI and Blockchain
This is the area where people have done presentations saying data is being stored on blockchains. As far as I know, current blockchains are not capable of storing a lot of data to begin. Then comes the issue of data privacy. Is the blockchain going to be private or public. To date none of the private blockchains are robust enough. AI and ML need very fast storage as well, and to date no blockchain based storage technology exists that can quench the needs of the AI/ML processing.
Hadera Platform
Hadera is a public blockchain platform that is based on the hashgraph consensus algorithm. Swirlds is a US based company and developed hashgraph, and now Hadera. The blockchain is based on a Directed Acyclic Graph (DAG) algorithm, it is very close to IOTA Tangle blockchain. Main difference in my eyes is that while IOTA Tangle does not have any transaction costs, Hadera transactions will incur some costs. Charging for transactions is a great SPAM and DDOS protection approach. Hadera will be operated by a board of directors from 39 large organizations, across the globe in multiple verticals. Although the main principle of blockchains is de-centralization, this idea of Hadera being managed by a group of elders is totally negating it. For a platform to be purely de-centralized, the platform decisioning should also be on chain just like Tezos is attempting to do.
Properties of Blockchains
The main properties of a blockchain are:
Distributed-highly available as there are multiple nodes.
Immutability– Data cannot be modified.
Replicated-all data is replicated across multiple nodes.
Transparency-all data written to blockchain is available to everyone to read. When it comes to crypto currencies, this property is questionable, hence introduction of privacy tokens that are trying to address the issue of privacy and fungibility.
Consensus-a mechanism to agree on writing data to the blockchain even though nodes are owned by parties who have no trust relationship with each other. While this aspect of trust is true for public blockchains, private blockchains operate in trusted environments. And the consensus mechanisms are usually monetary based for public blockchains and for private there are none.
Conclusion
Although blockchain is a cutting edge technology, it is not a solution to all problems. Always ensure you document the requirements first, and then look for a solution, and blockchain may well be the solution. So far teams are building blockchain based solutions looking to solve a problem, which is great for an ICO and collect money from poor souls who are just looking at it from “nice and shiny” aspect, and the fact that it is a great money multiplier. Of all the ICO’s I have seen, almost 95% have been failures.
In this brief introduction to self-sovereign identity, we will talk about how we build identity systems to create trust. Trust was something that was local and useful for establishing trust in a single domain. The only issue with existing identity systems is that they are not trust worthy. Still there is no good way to prove that you are a certain age, you have an account with a certain bank, etc. It is very difficult for someone else to vouch for you.
Initially identity was siloed, then came federated identity, and now it is time for user centric identity, this is what self-sovereign identity is.
Siloed Identity
In early days of Internet you had separate credentials for every site on the internet.
Federated Identity
Then came Facebook, and Google where websites enabled authentication using your Facebook or Google credentials.
User Centric Identity
In user centric identity, aka self-sovereign identity, user is in control of their identity. Open and flexible, interoperable and portable, viable and sustainable.
Verifiable Claims
Verifiable claims allow us to digitally do what we would do at a bar, pharmacy, hotel with a driver’s license. For example attributes on a driver’s license are called claims. A claim can be a JSON document that has been signed in a specific way holding certain attributes. Important properties of verifiable claim are:
They are decentralized and contextual
Anybody can be a issuer, owner, or verifier
Verifier does not need to have any kind of relationship with the issuer, not commercial, contractual, or technical.
Verifiers make their own trust decisions
Credential owner decides what credentials they want to carry around
Decentralized Identifiers(DIDs)
Decentralized Identifiers (DIDs) are a new type of identifier for verifiable, “self-sovereign” digital identity. DIDs are fully under the control of the DID subject, independent from any centralized registry, identity provider, or certificate authority.[From <https://w3c-ccg.github.io/did-spec/>]
Some key characteristics of DID’s are:
DIDs are a string of digits , cryptonyms derived from the elliptic curve private/public keys.
The DID is written to the ledger
DIDs provide pairwise identifiers for every relationship to prevent correlation. DID Descriptor Objects link DIDs to public keys and end points.
Verifiable claims allow third parties to provide identity owner with credentials they can use just like we do offline
Once the other system has your DID, they can lookup your public key, take a nonce sign it with their private key, send it to you, and then you can then sign the nonce with their public key and this way they can confirm that the person they are talking to is the person in control of the private keys.
They can then ask you for claims about information, create accounts associated with your DID.
Every DID has a unique Private keys, and something the user holds.
Every claim has a link to a schema , and the schema are written to the ledger. The claims schema tells you what the claim is about and what do the fields mean.
Anybody can write a claims schema and write that claim.
Key requirements
Any system that plans to implement self-sovereign identity, has to implement following mandatory requirements.
No data visible to network operators
No central database, which eliminates the issue with honeypots
Because it is distributed, there are no points of failure
Allows total privacy
Cannot track users across relying parties
Implementations
These are some of the implementations of self-sovereign identity
uPort is using Ethereum blockchain.
Blockstack is using bitcoin blockchain.
SecureKey is using Hyperledger Fabric blockchain.
Sovrin is using Hyperledger Indy blockchain.
Conclusion
Current self-sovereign identity systems are still very crude, they are still missing some essential tooling. Which will show up as the current platforms evolve due to learning from implementations.
GDPR(General Data Protection Regulation) impacts on service providers seems to be a very popular topic. I have published two shows, one explains What is GDPR? and the other about Privacy By Design principles. The idea behind this series is to bring awareness about GDPR and this show focuses on service providers, as they seem to be very confused when it comes to GDPR compliance. They are getting questions from their customers and are not sure how to respond.
Types of Service Providers
There are three types of service providers
IaaS: Infrastructure as a Service
PaaS: Platform as a Service
SaaS: Software as a Service
Roles
For each of the Service Provider types above, following roles can be assumed:
Role A: Storing info about EU citizens as a result of providing the service.
Role B: Storing info about EU citizens as they are your employees.
Role C: A regular service provider role, as in providing services to customers who might be handling EU resident data.
How am I impacted?
If you are a service provider assuming Roles A & B, you have to comply with GDPR Compliance. Service providers assuming Role C will be impacted depending on what king of service they are providing. If they are providing:
IaaS: This type of service providers will have not be directly impacted as a result of GDPR. The customer consuming the service will have to ensure that the service provider is engaged in all processes that involve GDPR data. For instance when it comes to data backups, the service provider does not know the exact location of the data, hence has no idea which backup has what data. The customer will have to provide instructions to the service provider on which backup’s to destroy and provide a confirmation that the activity was indeed completed. The customer is purely responsible for GDPR compliance. The customer is the Data Processor & Data Controller.
PaaS: In this scenario, the platform has to be designed as per “privacy by design” principles to ensure all GDPR requirements are addressable such as data locations, data export format, retention, backups, etc. The customer is responsible for ensuring that the platform they select is GDPR compliant. The service provider is the Data Processor and customer Data Controller.
SaaS: In this scenario, the software has to be designed as per “privacy by design” principles to ensure all GDPR requirements are met. The software should be able to address following Rights of the Data Subject, Consent, Access, Deletion, Modification, Portability, not to be subject to automatic data profiling. As far as Breach notification goes, Data Processor will immediately notify Data Controller, and the Data Controller will notify the authorities and Data Subjects of the breach within 72 hours
Conclusion
The bottom line is that a service provider has to ensure the products they offer in the market are GDPR compliant and are designed as per “privacy by design” principles. There is no GDPR compliance or certificate that a independent 3rd party issues. It will only become an issue when a breach is reported. Furthermore, it might be easy for GDPR regulator to enforce it within EU, but it is a totally different story how it will be enforced or enacted outside of EU jurisdiction.
