This week Facebook bought the Boston-based Confirm.io for an undisclosed amount. Confirm.io runs ID authentication checks on any government issued ID. They do it on the spot and without retaining any personal information.
It surprised me how shallow most reporting around this was. The fact that Facebook is buying a company that works on Proof of Identity is very telling. Not only telling but it could have massive consequences for other businesses.
Facebook has demonstrated they're extraordinary at scaling. The drawback is that they're awful at knowing who their users are. Yes, they can segment and micro-target like anyone. But they still can't differentiate a persona from who that person is. Facebook isn't alone on this. Any scalable platform is wrestling with the same issues. From Twitter to YouTube to Instagram.
For years, the goal has been to grow. To scale at any rate. To swell no matter what. Trust has been one of these values that we've thrown out of the window. Trusted news? Nah, I get them on my social network. Trusted opinions? Nah, I get them from my Internet friends. Trusted recommendations? Nah, I can ask for the wisdom of the crowds.
Only now we're realizing what the lack of trust can bring upon us. Lack of confidence is manipulating opinion, polarizing countries. It's pushing them towards civil conflict, or worse.
So governments are taking things into their own hands and demanding accountability. Part of that liability is being able to know who the user is. This is, by no means, unique to Facebook. Banks and other industries are required by law to identify their customers. So is Facebook really that different from Paypal?
It's not surprising though, that Facebook is buying a company that can bridge the final gap, tying a user with a physical identity. This way they appease Congress' wrath and try to sidestep any potential regulation.
"Our simple API lets you integrate in minutes, and confirm a person’s identity for any transaction that requires or benefits from proof of identity."
So what transactions benefit from Proof of Identity? There are a couple of obvious candidates. One, which most journalists are pointing out, is proof of ownership. You can link my Facebook account to your government ID card. You can then prove ownership of it by producing your document and comparing both. This scenario though isn't the most critical for the company's interests. The scale of ownership requests pales compared to other situations.
The most critical transaction for them involves an exchange of goods. In this case, advertising inventory. Right now, anyone can buy advertising on the platform, without verifying who they are. As long as you have a valid account the company can charge, the rest is mute. The company does this at scale through automation. This means they process thousands of ads per day. It would be impossible for them to confirm each advertiser by hand. This wasn't a problem until Congress starting demanding liability. They needed a scalable solution for this, and fast. This is where Confirm.io came in handy. The amount of advertising transactions per day is orders of magnitude bigger than any ownership claim. Hence the strategic acquisition.
Adding an ID verification step will impact their growth metrics. They know it. But having Congress take matters into their own hands would be worse. Also, they already command, with Google, the majority of the online advertising market share. While they'll feel the hit, they're still an aggregator, and they'll retain most legit users. This is due to the simple fact that they own the user's relationship like no one else does.
The moment Facebook rolls out the change, it will set a new precedent. One that will have broad ramifications. Governments might pass regulations that enforce such verifications. They can even extend it to another type of transactions like posting news.
The potential for abuse doesn't stop there. Confirm.io ensured they didn't retain any personal information. We don't know what will happen in the case of Facebook. Once again, we have to trust Facebook, something that's becoming harder and harder. No wonder decentralized platforms powered by Blockchain technology are gaining adepts.
Another ID company called SheerID raised 18 million dollars this same week. The Portland organization focuses on verifying specific sectors of society like students, teachers or the military. Their goal is to enable their customers to check their users and decrease coupon or discount redemption fraud.
While a lofty goal, companies can also use their verification process to segment and discriminate their users. It's one thing to use your internal data to infer, with a specific probability, what segment a user is in. It's a very different thing to know it as a fact.
The verification conundrum
The verified vs. anonymous dilemma isn't easy. Where do you set the line? Operating anonymously is one of the critical allures of the Internet. One that has brought much-needed change to decadent power structures. Under the cloak of darkness, lies the possibility of abuse and impunity. The unchecked, uncontrolled freedom of anonymity, paired with our current autonomous systems, can tear the seams of society too.
Verification should be an option for most, a necessity for others. The question remains, what kind of superpowers we ascribe to verified users? Should the platforms treat them with deference? There is no easy answer to this question. It's not black or white. The use cases aren't deterministic and will need to evolve and change as society itself changes.
There are significant ramifications here. Will other platforms adopt similar verification policies? Will Google? Will YouTube? Will Medium? If you're an advertiser on these platforms, how will you handle this? Who will be responsible for your company?
Will other governments start enforcing verification through regulation? The EU Commission comes to mind. Will we see age restrictions implemented on the Internet through ID verification? Any rule to such effect will always hurt the smaller players. Big agents already have the scale and virtuous cycles. These dynamics enable them to keep adding users, despite the increased friction. That's not the case for startups.
Last but not least, I wonder if the enforcement of identity verification can open the door to other incumbents. It's easy to imagine a new player offering unrestricted ads, bot-friendly uploads, anonymous posting, etc. While some countries stifle growth with regulation, other locations might take advantage and create regulatory safe havens.
I'm all for the return of trust, but anonymity is a precious gift too. It's important to balance both if we don't want to live under authoritarian regimes. It's time for the pendulum to swing towards more controls and verifications. Let's hope it will turn back to a more balanced view soon enough.
Despite my admiration for the underlying technology, I can't but cringe at the current fervor around the space. The industry is riddled with fraud, wannabes, and ignorant. This wouldn't be a problem except for the fact that we're playing with sophisticated technology and people's money.
One of the hottest cryptocurrency areas within the recent fever is Smart Contracts. When, years ago, I dove into Blockchain technology, Smart Contracts were in their infancy. Plenty has changed since then.
It now seems prudent to go on an exploration of what are Smart Contracts and how useful are they. Are they a fad? Do they even make sense? Who should use them? Is it wise to get your company involved?
What is a Smart Contract?
In 1997 Nick Szabo coined the term Smart Contracts to describe the digital automation of certain aspects of traditional contracts.
A contract is a set of promises agreed by two or more parties. It has been the standard way to formalize relationships in society for millennia.
A contract isn't limited to paper, but to any promise agreed upon, implicitly or explicitly. For example, we can make an agreement between a client and a freelancer. The freelance promises to deliver on what the client wants. The client agrees to pay the freelance a negotiated fee in exchange. If the freelancer doesn't provide or the delivery doesn't perform as the client approved, then there is a breach of contract. The client is then entitled, upon their contract, to withhold the freelancer's fee.
This is an elementary example, but one we're very familiar with. In this case, the contract is explicit, but it could also be implicit. Every time you go to a Parking, you implicitly agree to a contract with the parking owner. You can park your car, but in exchange, you need to pay for the use of the space. Upon payment and delivery of the proof of payment, the parking barrier will let you out of the structure.
So you see, in a way, contracts are what binds most of our social interactions. Some of these agreements are formal; others are informal. Some are explicit; others aren't.
The notion of contracts though entails several problems. The first one is the enforceability. Often, contracts end up in dispute because the parts can't agree on the performance of the delivery. Other times, one of the parties breaches the contract and cheats the other side.
The second problem is transparency. In some cases, there are some information asymmetries between the parts. One side might have inside information, putting the other part at a disadvantage when negotiating the contract.
Last but not least, there is no universal set of rules that apply on a global scale. The way we negotiate the terms of a contract; the dispute resolution laws; or even the consequences of a breach of the agreement, will vary wildly between jurisdictions, cultures, and continents.
"The basic idea behind smart contracts is that many kinds of contractual clauses (such as collateral, bonding, delineation of property rights, etc.) can be embedded in the hardware and software we deal with, in such a way as to make breach of contract expensive (if desired, sometimes prohibitively so) for the breacher.
Smart contracts go beyond the vending machine in proposing to embed contracts in all sorts of property that is valuable and controlled by digital means. Smart contracts reference that property in a dynamic, often proactively enforced form, and provide much better observation and verification where proactive measures must fall short." (Emphasis my own)
I can't but admire Szabo's prescient mind. Not only did he predicted the potential of cryptography to secure binding contracts, but he also took a pass at the future state of the Internet of Things (IoT).
In a nutshell, the idea behind Smart Contracts is to use programs to enforce the clauses of a contract, and cryptography to ensure non-tampering, transparency and fraud protection.
At the time, the technology couldn't deliver on all this. Bitcoin, Blockchain, and Ethereum changed that.
Early days of Smart Contracts
As technology and broadband started evolving, the future of Smart Contracts became the present.
The increase of Internet penetration and the rise of the cloud computing paradigm started allowing complex deployments with global reach.
Smart Contracts started appearing everywhere. Amazon's one-click, Amazon Web Services, Salesforce Software as a Service concept, etc. These systems allowed the deployment of automated enforcement of social contracts. The systems supporting them became distributed and automated, fulfilling part of what Szabo envisioned.
There was still some unresolved problems with such architectures. It lacked two key components, transparency, and decentralization. Transparency to know what set of rules govern the contract, what information is the other part storing and what are they doing with it. Lack of transparency puts the security of the deal in jeopardy. While one party promised privacy and security, the others had to trust it was so blindly. The infinite string of hacking incidents, some with disastrous consequences, is a testament to how problematic this has become.
Decentralization was also lacking. It ensures the integrity and enforceability of the contract. If the contract is own by a single entity, it's easy for them to change the terms of the contract unilaterally and even to avoid the enforceability. Decentralization allows for independent verification and makes it harder to commit fraud.
The rise of Bitcoin and the Blockchain
In 2009, Bitcoin became operational and brought to the market the first decentralized digital currency. The underlying technology, the Blockchain, suddenly makes genuinely decentralized computing a reality. On top of its decentralized nature, the way the Blockchain operates includes mechanisms for trusted consensus and irrevocable operations. Some start seeing the potential of the Blockchain as a vehicle to implement the missing pieces for Smart Contracts adoption.
With a strict focus on the currency aspect, Bitcoin though remains very limited. The Bitcoin team ignores voices asking for an expansion of the protocols. An extension that would enable more advanced uses of the Blockchain.
One of those voices was Vitalik Buterin, co-founder at the time of Bitcoin Magazine. In 2013, frustrated with the lack of action, he starts working on a new system, inspired by the Blockchain, but with a focus on computation.
"What Ethereum intends to provide is a blockchain with a built-in fully fledged Turing-complete programming language that can be used to create "contracts" that can be used to encode arbitrary state transition functions, allowing users to create any of the systems described above, as well as many others that we have not yet imagined, simply by writing up the logic in a few lines of code."
In July of 2015, Ethereum comes to life. The system builds on the idea of Blockchain and uses its characteristics to develop the first distributed, decentralized secure Turing Complete computing platform.
Ethereum Smart Contracts
Ethereum, while inspired by Bitcoin, is an entirely different beast. It's wrong to think of the network as a version of Bitcoin, because, while it employs similar elements, it's goal and capacity is quite different.
The Ethereum network is like a big distributed computer where you can run code in a distributed and decentralized way. In the same way, you used to pay for time on a supercomputer; you also pay for the time your code runs on the Ethereum network (Note: Ethereum charges per executed instruction, and not time per se).
Ethereum was designed to support the creation of Smart Contracts. Under the system, though, we should understand contracts more as programs and not just contracts. Ethereum's primary scripting language is called Solidity and enables some basic programming operations.
Solidity programs are executed on each node of the Ethereum network by the Ethereum Virtual Machine (EVM). Each node of the system runs the program simultaneously. This synchronicity ensures the anti-tampering of the execution. But It also imposes severe limits on the computational capacity of the network.
As I said before, executing code on Ethereum isn't free. There is a cost, both regarding network use, the number of instructions executed and storage used. To pay for all this, you need to purchase Ethereum's digital currency called Ether.
Ether's goal is to pay for resources in its network, while Bitcoin was designed to operate as an alternative to fiat currencies. Here lies a big difference between both systems.
There are a series of implications to this that are critical to Smart Contracts. Ethereum enables any developer to code a simple program that runs in a distributed, decentralized network. Once we send the application to the system, the code and it's associated data (storage database) will get replicated around the network. Our code is now secured, replicated and protected against any tampering.
Once stored, the Ethereum Blockchain assigns a unique id (or address in Ethereum parlor) to reference the uploaded code.
We can then trigger the execution by calling the program at that address.
Ethereum transactions and code execution
While on a regular computer we interact with it via clicks, in Ethereum we interact with transactions. There are three kinds.
The first one is the essential currency exchange between two accounts. The idea is identical to Bitcoin. We might want to transfer, split, share or give Ether to other people.
The second kind of transaction is slightly more complicated. It's a transaction than uploads our code to the network (Contract creation). The transaction will send both the code and the money to pay for the execution (gas). The system will return the address we can call upon to execute our program.
Once the code is on the network, we can use the third transaction to execute the program. In the same way as before, we transfer money to the program's address, and this will trigger the execution.
Ethereum Smart Contracts caveats
The fact that Ethereum even exists is already impressive. Nevertheless, it's important to understand that its capacity and utility is far from perfect.
There are still several problems with Ethereum and its Smart Contracts that are worth highlighting.
For starters, the current interfaces to manage its Smart Contracts are crude. It begs to remember what Szabo mentioned in his 1997 article:
"To properly communicate transaction semantics, we need good visual metaphors for the elements of the contract. These would hide the details of the protocol without surrendering control over the knowledge and execution of contract terms.”
That's not the case for Ethereum. Even if you best coders craft a fabulous contract, it's essential to design an abstraction layer to hide the protocol details. This hasn't been the case and won't be for a while.
Ethereum Smart Contracts are severely limited. On the one hand, it only allows you to build elementary logic (IF This Then That style). On the other side, it's not easy to import data streams from outside the network. External information is relevant to bot negotiating clauses and analyzing the performance of the contract. Without external validation, the use of such Smart Contracts is severely limited.
The workaround is to employ what's known as Oracles. These are programs that connect the Ethereum platform with the outside. They allow Ethereum code to import external data feeds. There are two issues with them though. For starters, it's hard to secure the information that comes from an Oracle. Due to the secure nature of Smart Contracts, any information used to execute it also needs to be ensured through a chain of custody. This is not easy and requires the use of trusted Oracles. The second concern is that Oracles make Smart Contracts expensive. Using an Oracle incurs on higher processing fees within the network. This might render the advantages of running it on Ethereum mute.
Immutability of code
Once we upload the code to the network, it becomes immutable. This is by design. The problem though is that updating or upgrading the contract becomes a nightmare.
It's tough, if not impossible, to preempt all potential scenarios of a contract. Not being able to fix an issue with a contract is a blessing and a curse. A blessing because it prevents any part from unilaterally changing the rules of the game. But it's also a curse because it stops any change that fixes a non-desired consequence for all participants. There are potential workarounds, but they aren't simple or cheap.
"Although code is theoretically immutable, one can easily get around this and have de-facto mutability by having chunks of the code in separate contracts, and having the address of which contracts to call stored in the modifiable storage."
Another effect of the immutability is that whenever we update a contract, we need to upload new code. Code that the Ethereum network will give a different address. The contract owners will require notifying all the parties with the repercussions this has.
Coding Smart Contracts isn't easy at all. The Ethereum network is a concurrent system. This brings to play all the known problems around parallel programming. And while the EVM executes operations synchronously, Solidity's code is still vulnerable to other effects, like reentrancy attacks.
Many developers out there have no experience with concurrency. Much less with concurrency-related security bugs like race conditions or reentrancy problems.
"We knew that programming, in general, is difficult, that most of the valley runs on cut&paste from stack overflow, directed by technological decisions made by reading hearsay carefully planted by marketing professionals masquerading as programmers on social media.
It's just difficult, what with all the Slack chat and Pokemon Go effort, to get all of those pesky little pre– and post-conditions right to build solid code that actually works. We also knew that some notable professors had given up on trying to teach concurrency to their students, instead preferring to teach them how to use "event-driven" frameworks. An "event-driven framework" is just some code that someone else wrote where the framework "handles concurrency" (a.k.a. kills it) by grabbing a mutex and making it impossible for the student's code to take advantage of concurrency, thereby avoiding concurrency bugs."
The need of expert developers, the use of a sophisticated concurrent system and the severe economic consequences of any bug in the code, make the development of Smart Contracts a nightmare.
On top of this, the most recent studies have determined that while Ethereum is much more decentralized than the Bitcoin network, the control of the network is still in the hands of a few.
"Put another way, there are more Ethereum nodes, and they are better spread out around the world. That indicates that the full node distribution for Ethereum is much more decentralized.
Part of the reason for this is that a much higher percentage of Bitcoin nodes reside in data centers. Specifically, only 28% of Ethereum nodes can be positively identified to be in data centers, while the same number for Bitcoin is 56%."
As I mentioned before, the performance of the EVM and node processing is quite limited. There are several projects (Raiden project, Blockchain sharding) that are trying to speed up the network and EVM's performance.
"Currently, in all blockchain protocols each node stores all states (account balances, contract code, and storage, etc.) and processes all transactions. This provides a large amount of security, but greatly limits scalability: a blockchain cannot process more transactions than a single node can. In large part because of this, Bitcoin is limited to ~3-7 transactions per second, Ethereum to 7-15, etc."
Until the network doesn't scale, most Smart Contracts will only be toys. Speed and performance are critical for more complex contracts.
Maybe the cost of operations is the major problem with Smart Contracts. As we pay per execution, having long, complex contracts are prohibitive. Also, storing data on the Ethereum Blockchain is also extremely expensive.
“Storing vast amounts of data to the blockchain is also not an ordinary task. Depending on the task, a user would likely store a cryptographic reference (a hash) of the data on-chain and keep the rest of the data off-chain.”
As more people speculate with the cryptocurrency, the price will keep oscillating with virulence. This has massive consequences for any Smart Contract deployment at scale. It's hard to sell someone on this, and then have them pay exorbitant prices that offset the benefits of having a Smart Contract.
Should you use Smart Contracts?
All in all, we've gone a long way from that initial theoretical concept that Szabo exposed in 1997. That said, the current solutions aren't quite there yet.
We live exciting times, and I believe we need more experimentation in the field. But I also think most organizations need to ask themselves the following question.
Do we need such a trusted and secure environment for our contracts?
Current technology like Amazon Lambda and other serverless computing offerings can achieve much more than the Ethereum computing platform. And cheaper. Orders of magnitude cheaper.
They lack decentralization and transparency, but it begs the question, is it critical for everyone? Security is about tradeoffs. The more secure, the more unusable the system is. Each organization needs to set their balance. Each company has a different customer. The use of Smart Contracts and the underlying platform needs to be aligned with the needs of those customers.
I don't believe that everyone should be building Smart Contracts on Ethereum. There are some edge use cases where it makes sense though. One of the aftermaths of the network's decentralization is the capacity to bypass the local law. Sometimes, the fact that the rules are the same all across the globe makes the underlying operations easier. Other times, giving a chance to people to bypass dictatorships and their censorship can have enormous repercussions.
As with all technology, it's important to understand it and measure the cost-benefit for our organization. Smart Contracts and cryptocurrencies are hard and complicated. They're sturdy and jaw-dropping, but they're also dangerous, unstable and volatile.