Page tree
Skip to end of metadata
Go to start of metadata

Date

Attendees

Goals

  • Revise concept map

Discussion items

TimeItemWhoNotes
3minAntitrust Policy


5minIntroduction from people new to the call All John, Sumit and Alexander introduced themselves.
30minDiscuss SCs Concept MapAll

We discussed some of the concepts, John proposed some additions for the Law branch which were added.

Sumit proposed some changes for IoT to be included along with AI. Sumit said he will add these changes later.

Alexander proposed that should be a way to distinguish Hyperledger from Ethereum Smart Contracts. Generally

if smart contracts on different platforms have many differeneces which affect the taxonomy then we should

find a way for this distinction.

20minDiscuss presentations about SCs for next meetingsAll

John offered to make a presentation of the Accord project he is working on. Sumit offered to contact with the

University of Nicosia to find out if they wish to participate, either with a presentation or genereally at the group.

Audio Recording

https://drive.google.com/open?id=1zgk7-Bc3EC_XX8d_HrMjb9roGVJ4EhI6

3 Comments

  1. Thanks for recording these sessions Sofia and thank you to all the participants - I just wish the meetings were at a time of the day that I could participate. I'm in Melbourne which is GMT+10. I'll follow the meetings through the recordings for now.

    A few specific comments on the 11 March meeting:

    • As was mentioned during the call, some lawyers will be necessary for the meetings (which I'd love to help with if the timing was better). I didn't hear anyone with legal background comment on the suggestions which could make things difficult if the WG intends to build a working knowledge of the key concepts required for this tech. There were many comments made during the call regarding contract law that were inaccurate but which would be easy to correct with the right people on the call.
    • In this regard, a Contract Law 101 should be a pre-requisite for all participants of this WG. Happy to provide some useful materials to assist with that. Without a basic understanding of contract law, I'm concerned that time could be wasted debating issues and opinions based on misunderstandings.
    • I'd like to see a clear distinction between smart contracts (meaning actual contracts, recognised at law which happen to be built in chaincode) and simple chaincode (not recognsised as a contract but still containing useful functionality). I think the use of "smart contracts" isn't helpful unless the distinction is understood.
    • We need to remain cognisant that the Hyperledger definitions have moved away from "smart contracts" to "chaincode" so that the above distinction remains clear. This WG should retain the correct definitions so that our work better aligns with the broader Hyperledger program.
    • Finally - just on teleconference etiquette, I felt there was too much background noise. It would be good if we could have a rule to mute our devices unless speaking or intending to speak.

    Looking forward to providing more input and hopefully I'll be able to attend meetings and introduce myself to everyone. It sounds like a great team!

  2. Hi Paul, thank you for your comments! Just a quick reply on some of them

    • It will be highly appreciated if you can be more specific about the "inaccurate comments during the meeting" and maybe make some suggestions on how to correct them. 
    • Please do provide the material for Contract Law 101.
    • A certain distinction between contracts containing law terms and those that don't is achieved, but of course, you can make it more clear. You can directly edit the map and make additions.

    The best would be to attend the next meeting and discuss all these matters. The poll about the date/time is closing today, you can find it here https://wiki.hyperledger.org/polls/viewpoll.action?guid=27b8f2e09f024f80abdf8ae24db9c886 and we have a winner. The day is going to be every other Wednesday at 3 pm GMT. I will send an announcement for this (probably early next week).

    Hope to hear from you soon!

  3. Hi Sofia and team:

    Detailed Notes with timestamps:

    •  10:00-18:00 Taxonomy: The discussion of an appropriate taxonomy of smart contracts referred to matters that would not be central to a sound taxonomy of contracts, let alone those represented in code. For example, there was extensive discussion of compliance and governance in relation to contracts however contracts rarely concern themselves with those matters unless it is central to the agreement.
    • In most commercial contracts for example, governance and compliance can be addressed in 1-2 sentences along the lines of "Party A must comply at all times with applicable law" or "Party B will comply with all applicable privacy and data protection laws". Sometimes, these clauses can provide greater detail but this is typically a requirement of the contracting party (e.g. Organisations operating in heavily regulated environments such as banking or health) not a requirement of a sound, enforceable contract.
    • It is even possible to completely omit such clauses because they are not an essential feature of contracts and from a public policy standpoint, it goes without saying that a party will comply with all applicable laws. The benefit of such clauses is limited to granting the non-breaching party the right to terminate the agreement (and even here the right to terminate is fairly limited unless the breach is significant enough or the termination clause grants a specific right of termination for any breach of applicable law).
    • There is still an important question of taxonomy of smart contracts and whether that should reflect a taxonomy of normal contracts or seek a new model. One option would be to being with a taxonomy reflecting legal contracts and expand from there. Smart contracts are able to achieve outcomes normal contracts cannot and the taxonomy needs to recognise that.
    • Maintaining a bridge between the tech and the law: One comment I did agree with was that we need to continually find a bridge between software code and the thing it is meant to represent (contracts). That means however, that the software developer needs to understand what a contract is, why contracts are as they are and the what requirements are necessary to satisfy the essential nature of a contract.
    • 18:43 Enforceability "Enforceability is sometimes important" - Enforceability is an extremely complex problem for smart contracts. From a legal standpoint enforceability is always important if one is attempting to construct a smart contract. I agree that court-mandated enforceability of rules is not a requirement of everyday life but lack of enforceability would be catastrophic for a contract as this means there isn't a contract and if that is true, then there isn't a smart contract.
    • The second reason why enforceability is critical at all times, especially when dealing with Turing complete programming languages is because there must be a result/output of the code (I include termination of the code as a possible result as well). There cannot be indeterminacy or endless loops. Code always enforces an output. Enforceability is an inherent feature of code. But what if the output of the code is unenforceable at law or even unlawful? Can we call such code a smart contract if it fails the basic tests of contract law or offends the law?
    • And from the other side, how does one introduce unenforceable outcomes in code where enforceability is not critical for the particular application? Is that something that smart contracts should concern themselves with?
    • I would also like to introduce the concept of recognition. Currently, the courts would not recognise smart contracts in many cases. Recognition can be achieved by either (A) having the enforceability tested in the courts applying existing contract law to determine if a specific piece of code has produced an enforceable agreement or (B) lobbying for legislative/regulatory certainty. I believe the latter to be a quicker and more effective outcome if handled correctly. Is the WG intending, as part of its Charter, to lobby for legal recognition of smart contracts?
    • 19:00 Certainty - in a contract setting, certainty is absolutely necessary. Without certainty, there is no "meeting of the minds" which renders the contract void. Code is absolutely certain as it produces a result. But is this result one that all parties to the smart contract intended? This is not simply a matter of translating contracts into code, this is about uncovering the intent of the parties and ensuring the code reflects that intent.
    • 28:20: Categories of Tech and Law: I agree that there needs to be a balance of both the tech and the law in this space. I still recommend that the WG consider reverting to the official Hyperledger terminology of "chaincode" where there is uncertainty about the nature of the code or where legal enforceability is not a requirement.

    A great resource to explain some basic contract law concepts and key challenges in the context of smart contracts is the following paper produced by Norton Rose Fulbright: https://sites-nortonrosefulbright.vuturevx.com/596/14051/uploads/r3-and-norton-rose-fulbright-white-paper-full-report-144581.pdf

    As much as I would love to attend the meetings, the times proposed are either 2am or 5am in Australia and I don't think I would be able to make those times a regular part of my schedule. I'll try my best to keep up with proceedings and provide feedback into the various artefacts produced by the WG where time permits.