View All Discussion

Substrate Integration in Openlaw

adridadou
5 years ago

Substrate Integration in Openlaw

Project Description

Integrate Polkadot/Substrate as a supported network in OpenLaw legal agreements and VM.

We want to enable OpenLaw users to create agreements that can interact with the Polkadot network by recording signatures, initiating contract calls and listening to contract events.

There are several changes necessary to integrate the Polkadot network. The OpenLaw language will be amended to support the definition of new networks at the agreement level and appropriate configuration entries added to the OpenLaw application to enable the new network at the server level. In addition, the OpenLaw Virtual Machine will require a new network provider implementation to be written to handle API interactions with Substrate-based chains. Finally, code that generates and verifies signatures, initiates contract calls, and handles events from deployed contracts must be updated to support the new network type.

Team Members

  • David Roon
  • Craig Blake

Team Website

https://openlaw.io

Legal Structure

Joint venture between Aaron Wright, David Roon, and ConsenSys AG

Team's Experience

OpenLaw is a Ricardian contracting system co-founded by Aaron Wright and David Roon.

OpenLaw has built a core set of tools that enables the creation of Ricardian contracts. Its core technology transforms natural language agreements into a computer-readable JSON object and also enables creators of agreements to trigger one or more smart contract calls.

These agreements can be automatically generated from an OpenLaw private instance or through a public or private API.

OpenLaw has also build various different work flow related tools, which enable users to pull in data from third-party oracle solutions, store agreement in centralized document management systems, and pull data from agreement into other data structures (like a spreadsheet)

The team has members, which contributed to the initial Java implementation of Ethereum, and played a small role in Ethereum's launch.

Team Code Repos

Team LinkedIn Profiles

Intended Language of Development

Javascript, Scala

Development Roadmap

Please note the team also has other features and work items outside of this grant application. The timeline below is not based on two people working full-time but rather cumulative 1 full-time person. Deliverables marked with * have a detailed list of types/methods that will be implemented in the next section "Specification Details"

Timeline and Milestones

Milestone 1

To set up an agreement, the agreement needs to be "marked up" using OpenLaw's markup language.

In order to integrate with Polkadot, the Markup Language needs to be updated to acccomodate language-level and application-level constructs to define new networks.

On the language level, OpenLaw needs to update the way smart contract calls as well as OpenLaw smart contract event listeners are being defined so they can accept a Polkdot node / network definition.

This needs to be done and validated within OpenLaw templates and workflows.

Changes in the OpenLaw template language whereby signed legal agreements can trigger smart contract calls on Polkadot

Duration: 2 weeks

Deliverables:

  • New syntax to inline network definition (as opposed to just the network name) with type check in Ethereum calls and Ethereum event listeners
    • node url
    • chain id
  • Change data structure from enum to a type for network definition with validation

Funds Requested: 800 KSM

Milestone 2

Users of OpenLaw can set up a private instance whereby they can manage the agreements they want to use and also set up smart contract calls.

These private instances have an "admin" page where a user can select the blockchain they want to use for smart contract calls. We need to update the admin page to be able to select one or more Polkadot substrates.

Duration: 2 week

Deliverables:

  • create new page to see the definition of every networks (by default you have mainnet, rinkeby, ropsten and kovan)
  • repurpose the private network configuration to edit each new network
  • new add /edit / delete function for the networks
  • each network can be used in the template / flow language
  • set by default the common nodes, if it makes sense we can add the common nodes from Polkadot as well

Payout: 800 KSM

Milestone 3

Each smart contract call that interacts with OpenLaw needs to open a connection with a specific node, send the request and listen to the result.

We need to update the way orchestration is done to only open up to a certain amount of connections to Polkadot to avoid starving the server.

Duration: 2 weeks
Deliverables:

  • Modify the EthereumFacadeProvider to connect to custom networks
  • Create a connection pool to avoid issues
  • Test with Polkadot nodes to make sure that the functions we use for Ethereum calls and Event listeners work
  • Define relayers where possible (for calls made by Openlaw itself)

Payout: 800 KSM

Specification Details

The milestones are organized in layers

Layer 1: Language layer

We want to make sure that a user can define the connection to one of the chains within Polkadot for agreements and flow

Layer 2: Admin layer

Admin part is important to pre-package those networks and make it easier and more portable to work with. By having a common name, people can use different nodes for the same network

Layer 3: applicant / orchestration layer

We need to integrate these changes so that anyone can simply integrate any chain within Polkadot in their template or flow

Funds Required Overall

2,400 KSM

Additional Information

The implementation is based on the fact that each side chain in Polkadot is compatible with ABI v1 encoding.

We are not yet supporting ABIv2 but it could be added if necessary.

Also, we know that some parachains will have rust smart contracts and the question here is whether ABI encoding is compatible with it or if we will need a new encoding for them. That could be scoped later if needed.

Edit:
Thank you JAM for all the clarification. Looks like I've misunderstood what is needed to bring most of the value to Kusama.

I'm currently working on a rewrite of the grant here

I'll update everybody here and on other channels once it's ready to be reviewed again.

My challenge here is to make sure to have milestones that bring value to the community and dont take too long to be completed. This way we can show progress regularly and always adapt the next milestones if needed

Comments (2)

5 years ago

I'm a big fan of the general idea of integration, but:

The implementation is based on the fact that each side chain in Polkadot is compatible with ABI v1 encoding.

We are not yet supporting ABIv2 but it could be added if necessary.

Also, we know that some parachains will have rust smart contracts and the question here is whether ABI encoding is compatible with it or if we will need a new encoding for them. That could be scoped later if needed.

will probably be something you should look into earlier rather than later - it would be much more productive to implement the ability to make arbitrary extrinsics (which may or may not be smart contract calls) because as it stands, only implementing ABIV1 calls to standard (but custom) Ethereum endpoints, you're going to end up not actually building on top of or using any Polkadot tech whatsoever, you may as well be doing an xdai integration :)

many Substrate-based blockchains and parachains likely will not have any smart contract functionality in the near term - and Polkadot and Kusama themselves will likely never have smart contract functionality natively.

profile
adridadou
5 years ago

So right now, what you can do is create transactions to send value and prepare function-encoded data based on ABIv1. So here the point is more to say that you can do smart contract calls based on ABIv1 AND value transfer, but not ABIv2 encoding. Is there any other form of integration you can think of here?

PleaseLogin to comment
    Polkassembly - Substrate Integration in Openlaw #340