Editorial of May 2019


 by Célia Zolynski, Professor of Law at Université Paris 1 – Panthéon-Sorbonne
 and Alexandre Veronese, Professor of Law at University of Brasília

Blockchain and security: an important debate for the legal community (especially from the civil law tradition)*

When we read and listen about the Blockchain technology, its main revolutionary character is the praised new manner by which the users would extract a new kind of trust from the operations endorsed. At some point, some writers even detail its technical design as being trustless. This technology – as some of their enthusiasts say – would therefore make it possible to replace, rather than displace, the trusted third party – an important technical feature that exists in most of the modern designs of private or public relationships – in various kinds of transactions and operations. The Blockchain enables this feature because it makes possible to guarantee the keeping of an unforgeable and updated register of digital records in real time. The technical functions of the Blockchain promise to secure many possible applications. An example is the use of the technology to ensure the integrity of a document or a digital archive over the time by anchoring it in the Blockchain. In addition, it is possible to create Blockchain systems to control or trace the circulation of digital archives and packages and even their usage. The Blockchain technology could therefore be able to guarantee the security of the storage files in the blocks using asymmetric encryption protocols in a peer-to-peer model. However, ten years after the launch of Bitcoin, in 2009, we are still largely in an exploratory phase of that technology. The blockchain and its applications remain immature: technically immature and, we should say, legally immature too. Several difficulties hinder the transition from the small-scale operations to bigger ones. One of the main concerns of the Blockchain technology is the safety of the designed applications. Such issue – the safety of the Blockchain – needs to be more debated than praised in order to avoid some misjudgments and overstatements. Just to begin, we are going to provide a provocative statement: Blockchain does not grant actual and complete security; from itself, the technology – and its prophets – indulge us with the illusion of safe and security. Why? We will divide the text in three parts, in order to pose problems to the Blockchain. First, we are going to describe that some technical issues that are entrenched in the design can be vulnerable to attacks and difficulties. Second, we are going to mention that – in legal terms – the Blockchain registers still will need a third party to be feasible as evidence in the courts. Lastly, we will remark that the so-called “smart contracts” are not contracts after all.

The own technical features limit the safety of the Blockchain. We will give five examples of technical problems or vulnerabilities.

The first example of technical defy could be the security of the Blockchain protocols of connection in the distributed network and even its own engine (core). There are significant risks of security breaches and computer attacks. The original design of the protocol can also affect safety and reliability. This is the case if someone successfully tamper the system and somehow takes over the distributed consensus. This scenario can result from a “51% attack”.  It is widely known that the proof of work requires a high level of computing power. As a result, real oligopolies of computer power are currently in action: a few mining groups now holds computing power farms. Other mining communities may get together in a “mining pool” in which a central server centralizes the calculations made by many other linked computers. This is a raw power game or an arm wrestling. Whoever gets more power against the network takes control of it. This threat is more concerning when we think that, nowadays, we have more the fifteen hundred cryptocurrencies in the whole world.

The second example is hypothetical. All projects on the run with the Blockchain technology have a core program or an engine. That engine must be constantly updated and improved. In order to do so, there are two ways. The first way is to use a closed group of developers that cooperate to rewrite and test the engine. The developer’s community will release the deployment of the new engine version only after it is hardly tested and verified. The second wat of improving the engine’s source code is to have an open development community. Many developers will then rewrite and check the source code in an open and cooperative manner. Most of the Internet protocols are developed and improved in the latter way. The hypothetical gambit would be having a developer – or a group in the community – that could create a malicious coding in the engine, either in order to steal the control of the network or to implode it. This scenario is very different from the previous example. There, the keyword was brute force (computing power). Here, the keyword is infiltration and subtlety. Until today, we never saw an attack against the engine to succeed. Nevertheless, we all know that the DAO Project experienced an earthquake after the use a poorly coded smart contract drew funds from the Ethereum database.

The third example is the immutability of the Blockchain registered archives. The chained record of blocks can come into question if some attacks split the formation of the chain. We call that the fork attack. Such tactic also exists in the chess. We use two pieces to make a fork (double) attack against the opponent’s king. In the Blockchain, the idea is to force the splitting of the chain in two different register tracks. We saw it after the DAO Project attack. Some members of the network – nodes – have created a new track – Ethereum Classic. Some others decided to solve the situation without giving up the sacrosanct principle of immutability of the Blockchain. Thus, the division created a fork. In addition, a fork can emerge when some group of developers do not agree to implement an alteration of the engine or the source code. The splitting of a Blockchain may serve hacking objectives also.

The fourth example comes from the inner force of the technology. The technical immutability of the Blockchain can suffer risks because of its own public deployment. The security of a public Blockchain comes from the unforgeability of its registered chain. This distributed nature of the Blockchain secure the unforgeable feature. Since many nodes hold a copy of the registry chain, each participant of the network can therefore check its inviolability. However, what should we do when the Blockchain represents several Petabytes of data? Google process daily many Petabytes just to compare. In such hypothesis, the storage of the registry by the least powerful nodes of the network would become utterly impossible. If we think that the idea of the Blockchain is to maintain the original chain of blocks for an undefined amount of time, then the distributed and decentralized governance model could be a problem in the real long run.

Nevertheless, beyond the protocol, we can think about a fifth example. That is the issue of the security of the application layers. The Blockchain technology must adapted in a wide variety of sets in order to be useful to many applications. The applications layer is therefore susceptible to attacks. These include recent and increasing attacks on cryptocurrencies exchange platforms, problems with poorly secured private keys; and some poorly encoded smart contracts.

After the description of some technical problems or menaces, we are going to describe the problem that comes along with the necessity to convert the so-called trustless registers into legal elements. Putting into clear words: how would be possible to use Blockchain registers as evidence in the courts?

We can then demonstrate that the technical security of some usual usages is also limited, especially from the point of view of the legal system. We may deem something technically proved, although not legally binding as evidence. The proof-of-work calculations are largely in use in connected systems. They use asymmetric calculations – hard but feasible – in order to assess the integrity of information exchange among the nodes. The hard and complex mathematical base of those calculations provide a comprehensive array of solutions to maintain the stability and reliability of the networks. In asymmetric cryptographic systems, we can also use that ingenuity to sign digital archives and thus guaranteeing them as legally binding. The huge difference between those digital signatures and the Blockchain is that the former rely on certified third parties to grant the legal value. In Brazil, the Civil Procedures Code has some provisions about it along with the National Electronic Process Act (Federal Act 11.419/2006). Europe had the Directive 1999/93/EC, which France transposed in its National Act (“loi”) 2004-575 (Provisions about trust in the digital economy). The EU Regulation 910/2014 (eIDAS) took the place of the Directive and currently applies to all countries of the European. The absence of the certified third parties renders difficulties to the use of the registries as evidence in the courts.

Another problem is that the Blockchain only keeps a technical proof of the existence of a transaction. However, it does not guarantee the contents of the transactions actually carried out from it. For example, when can use Blockchain to prove that a person has created any intellectual product – like a music, an image or a text –, but the Blockchain technology cannot – in itself – guarantee the complex criteria to provide actual copyright protection to the owner of the creation or for the rights holder.

We can raise doubts about the legal value of a Blockchain registry when someone tries to use it as evidence provided. We will provide examples. For the time being, under the Brazilian, European Union and French legal systems, there is no text specifying the legal value of the elements registered in any Blockchain. Let us take the hypothesis that the object of the evidence is subject to the legal principle of freedom of evidence. In this case, the Blockchain registry can be submitted under a judge’ consideration. He or she will have the legal mandate to evaluate the registry and grant or not legal value. However, until now there are no case law yet on this subject, both in France and Brazil. This explains why in France some have proposed the reform of the Civil Code to endorse the potential use of Blockchain registers as court evidence. They propose to modify Article 1362 of the Civil Code in order to amend it to recognize legal value to the imprint of a document extracted from a Blockchain. By the way, the French Parliament rejected this proposed amendment of the Civil Code. Thus, as the French Law stands right now, it is necessary to provide for the “re-inking in the reality”. The material could become legal evidence after some other measures. In order to vouch the correspondence between the Blockchain registry and the reality, we can use a stamp granted by a court official – like a clerk or a judge. The http://www.blockchaininyourIP solution would need in France or Brazil, for instance, a certification from a public servant, like a court official, a judge or a public notary. Even in the United Stated, this application needs the stamp of a lawyer as its website shows. Therefore, the Blockchain alone cannot autonomously provide legal value to its registries in most of the current legal systems. In short, nowadays, the technical security does not mean legal security.

If the technical security is notwithstanding limited, as we describe, the overstated contractual security is also incomplete or non-existent. We will see about it when looking to the so-called “smart contracts”. We can criticize the prospects of security by assessing two points of the smart contracts. The first is that the idea of security comes along with the rigidity of the code. The second is that the security has to do with the context or environment, as we will see.

First, we can criticize the idea that excess security comes from the excessive rigidity of the smart contract. The smart contracts are based on the “if… them” computing mechanism. This idea has origins in the Alan Turing´s universal computer, described by him in 1950 (“Computing machinery and intelligence). The interesting point here is the automatic nature of the execution of the smart contract and its immutability. When we inscribe a smart contract to the chain of blocks, this therefore guarantees compliance with the internal terms of the contract thus executed. This also makes it possible to make successive transactions public. Nevertheless, this also limits this technique of contract execution. Any subsequent amendment of the contract is then impossible after its insertion in the chain of blocks.  In addition, neither party will be able to oppose its execution. We can then ask a question: can we use the smart contract to execute any kind of contractual relationship? Of course, we cannot. We cannot frame contractual relationships that demand mutability within smart contracts. They smart contracts only allow the execution of relationships or operations that are in essence automatic. The execution of operations that are free of all hazards. Moreover, they can inscribe only the execution of operations that do not require external or supervening factors. Right now, some experts are developing solutions to able the usage of the smart contracts to provide newer possibilities. An option is to provide in advance a set of conditions to the automatic execution of the smart contract in its code. Other solution is to provide the intervention of a trusted third party to take into account previously identified elements of flexibility. This is the solution proposed by Ethereum proposing the intervention of an “oracle”.

The second point that we are going to question is the security context or environment. Both security and reliability have a close connection to the social world that exists around them. We can ask some questions like “what about the security paradigm”. Alternatively, in other words, are there any comprehensive secure models? To begin with, we must know that some people fear that this so-called security turns into a rigidity paradigm, which will eventually impose itself as a new guiding principle in contractual matters. In this dystopia, the new motto of the Contract Law would change to “speed, security, and simplicity”. In legal terms, security has to be with a safe market and social environment, which comes along with a complete constellation of rights and duties. In theoretical terms, the legal security never came from the papers signed between the parties. It always came from the legal system and the society that made it stand.

However, the original feature of the smart contract is now turning to a race towards the best technical standards. There is a global forum about Blockchain standardization under discussion within ISO – International Standard Organization, in particular with regard to the security of the protocols and their technical probative value. Nevertheless, we are also witnessing a race towards “de facto” standardization. This race concerns in particular the language to code smart contracts. Some United States universities are carrying on projects to design smart contracts languages to encode the law. Consequently, semantic and deontological legal rules of law are under development in a new “computing law” that takes into account only the tradition of the Common Law. Right now, some legal researchers in Europe voice concern that this language may become the standard for encoding smart contracts and that this would result in the dissemination of the common law model through the standardization of computer code. To counterbalance this, some projects are therefore under way to develop codes adapted to other legal traditions. The debate will thrive. After all, the universal encoding of the law is a long and waited dream to the global legal community. Nevertheless, we are still very far from its establishment.

We expect that this short text could show that security – both technical and legal – is therefore an essential component of any Blockchain application. The text demands debate about it and not an effusive enthusiasm. Furthermore, we are solidly convinced that the security is necessary condition for any large-scale deployment of any Blockchain application. Actual and soundly security, notwithstanding, is requisite for pragmatic Blockchain promise to become reality and not just propaganda, unfortunately carried out by some prospectors screaming in an illusory gold rush!

* This text comes from the draft of the presentation made by Célia Zolynski to the French-Brazilian Colloquium held at the University of Brasilia from 9 to 11 April 2019 (Blockchain and Law). The second author – Alexandre Veronese – reorganized the original draft, added many information and then translated it to its current version. The authors wish to thank CAPES – Fundação Coordenação de Pessoal de Nível Superior –, the Brazilian federal administration higher education evaluation agency for the funding that made possible the activity in Brasilia. We also like to thank the three French universities and laboratories involved in the partnership – IRJS (Paris 1 Panthéon-Sorbonne), CEDAG (Université Paris Descartes) and D@NTE (Université de Versailles Saint-Quentin-en-Yvelines / Paris Saclay) and the University of Brasilia Law School and Dean Office.

Picture credits: Blockhain by TheDigitalArtist.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s