I came across this paper on Hacker News yesterday and decided to have a look at it since it merges two of my interests: distributed ledgers and procurement. The paper by Hardwick, Akram and Markantonakis proposes a theoretical framework for a tendering system based on smart contracts, running on the Ethereum blockchain.
I cannot comment on some of the substance, particularly the security arguments presented, but keeping to the theoretical framework for now I have two comments on (i)mutability and the idea behind smart contracts to provide.
(I)mutability of a tender is not a feature, but a bug.
The authors approach the problem of public contract tendering from a vector broadly in the citizen participation/open governance/system integrity/trust scope. Nothing wrong with that, and it is refreshing to see new takes on existing ideas without the constraints imposed by the current mental models.
On p.4 the authors put forward as a security feature of their proposal:
"R1) The tendering Organisation cannot change the tender once it is placed on the blockchain. If due to some unforeseeable reasons they have to change it, then they have to create a new tender (smart contract) on the blockchain."
Keeping legal considerations out of the way, I can understand the theoretical underpinnings of this proposal for immutability. However, it is very problematic on a practical basis: time and opportunity cost for everyone involved. Going back to square one every single time a minor error with the tender is detected or due to further information having been requested by the bidders is simply inefficient and disproportionate. If the objective is to ensure the security of the process and enable auditing ex post facto, this could be achieved by allowing changes to be made to the smart contract by the contracting organisation as long as all those changed states are tracked/timestamped as well. This would allow in my view to achieve the same objective but with lower transaction costs for the parties.
Smart contracts, not contracts
Next semester I will be teaching law and blockchain (also smart contracts) and this paper is a timely reminder how prose language can be tricky to interpret. What is described here as a smart contract (ie, the set of operations between launching a tender and awarding the contract) is perceived in legal terms not as a contract at all, but pre-contractual actions which may or not impose obligations on the parties (it varies from jurisdiction to jurisdiction) but not those of a contractual nature. The contract is the end result and usually it only involves two parties (the contracting body and the private party), not all participants in the procedure.
In essence as far as I can define smart contracts they are a set of scripts that run automatically in the same way they already exist in other areas that can lead to the formation of a contract (stock buying/selling orders at a pre-defined value come to mind). They are not (necessarily) by themselves a contract. Having said that, depending on the jurisdiction it is possible that smart contracts really are contracts assuming a) all the elements for contract formation are present (again, jurisdiction specific), or b) definition of what constitutes a contract changes in the future.
Where could this be used?
Coming back to the idea behind the paper - running public tenders on Ethereum blockchain - and where it could be used. My view about the use cases for blockchain in general is that it will be useful and used in scenarios where no other current technological alternative has been deployed or where trust issues are so profound that a centralised database would be more efficient but cannot be used due to lack of trust in the operators.
In both cases I cannot see countries which have already adopted centralised electronic procurement systems to jettison those in favour of a blockchain based system any time soon. Let's not forget the public sector tends to be a laggard in terms of technology and that even today electronic procurement is not mandatory in many countries (EU, I'm looking at you...) even though buying over the internet has been commonplace for more than 15 years. Small elements of what is proposed in the paper are being trialled in Aragon (Spain) but only as a mechanism to timestamp the delivery of bids and I have in the past called for a similar system to be created to gather contract feedback data.
I suspect the potential bulk of use cases will thus be in the developing world, especially those that do not currently have electronic procurement systems and where trust is a paramount issue. It is no surprise that mobile banking (on feature phones) took off in countries without strong bank branches penetration or even internet. And if banking can be done on low bandwidth phones, there is no reason why tendering could not follow a similar development path. Plus, on the long run piggy backing on a major blockchain like Ethereum may lead to a cheaper alternative than the set up and management of a centralised system.
Another potential scenario for use is for regime transitions, ie countries that have changed regimes and where the new one wants more transparency, quickly and where trust is - once more - an issue. Ukraine takes great pride (and rightly so) on developing and using ProZorro after the Maidan Revolution but the next Ukraine may find it easier and cheaper to achieve a similar result but without the need to deploy a centralised system.