Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

KIP-0003: Polkadot Integration #8

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
+68 −0
Open

KIP-0003: Polkadot Integration #8

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
68 changes: 68 additions & 0 deletions kip-0003.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,68 @@
---
KIP: 0003
Title: polkadot integration

Author: Emily Pillmore emily@kadena.io
Status: Draft
Type: Standard
Category: Integrations
Created: 2020-06-11
---

## Abstract

Request For Comment (RFC) from the Pact and Polkadot development communities. Soliciting feedback from the community to determine whether to deploy Pact Service on a Polkadot parachain[1][2], or implement a minimal Pact interpreter as a Smart Contract[3] on an existing parachain.

## Rationale

There are two options available when integrating Pact with Polkadot. Each option carries with it a particular burden in terms of both implementation and maintenance:

### Pact Service on a Parachain

Kadenamint on Tendermint is a recent example of a Pact Service integration. As shown in the Kadenamint[4] implementation, with the help of ABCI Haskell bindings (see: Kepler[5]) written by Kadena partner FOAM, we were able to implement a complete Pact Service using the existing, full-featured Pact language and interpreter to execute smart contracts on the Tendermint chain. This involved implementing a new database backend and data parsing scheme for Pact Service, allowing the service to work with Tendermint data. This integration allowed for a full-featured Pact implementation, reusing the existing language and all of its features and endpoints.

This Pact Service implementation provides several benefits. For example, all Pact smart contracts authored by dApp developers are immediately available on Tendermint or Polkadot if we implement a Pact Service. This is because the Pact transactional layer is agnostic of blockchain: if there is a way to feed Pact transactions to a Pact service, and a serviceable storage backend exists, then Pact will work.

However, implementing a full Pact Service on a Parachain will require running and maintaining a parachain service, which would need to be maintained either by Web3 or the Polkadot development community.



### "Core Pact" in a Polkadot Smart Contract

To address Polkadot's on-chain size requirements, we have also designed a "Core" Pact sublanguage and associated interpreter. This design includes a specification of an interpreter for an untyped variant of the Pact smart contract language. This variant would be a minimal, untyped calculus produced from typechecked Pact programs, that aims to capture as many features of the language as possible, including the guards and capabilities-based security model, the notion of user-defined schema and tables, modules, pact continuations, and the standard library.

The interpreter itself is based on a well-understood standard--the CEK machine with continuation marking--which is a statically-analyzable extension of CEK machines. Because such an interpreter is necessarily small, and because the minimal, untyped Pact calculus has only a handful of constructors, there should be no sizing issues with a Polkadot integration. Further, if the proposal takes us in the direction of WASM integration, this untyped calculus is readily compilable to bytecode and translatable to WASM using a Guile-esque tower of intermediate representations. The end result is a calculus that allows us to integrate with many different formats, across many different systems.

The current Pact syntax tree integrates heavily with Haskell for performance and security, leveraging the existing production type system to its advantage. Due to the size constraints inherent with systems such as Polkadot, where an interpreter must be shipped with code, the language cannot fit as currently designed into such a framework. To address this, the Pact language (de)serializes the syntax trees of whole programs to make sure code on chain is human readable for authors and users alike.

These changes provide a surface area for paring the language down to just a minimal core calculus, devoid of these features. In order to implement standalone Core Pact, we must first make sure that the program is sound by type-checking, and then we must execute a compilation to a more minimal syntax tree, stripping the program of its types, unnecessary variable names, and source positions. The end result will be much like an extension of the untyped lambda calculus with row literals and a more robust security model.

CEK machines are well-studied, compact machine representations of the lambda calculus, and can be made to execute quickly, robustly, and safely in any context - regardless of platform. The tenets of this interpreter are:

1. It must fit within a Polkadot Smart Contract
2. It must be able to run all existing Pact code
3. It must retain the safety guarantees promised by Pact proper.
4. It must do so without sacrificing performance.

While a minimal calculus would provide an effective standard for executing Pact programs on any blockchain, it relaxes one of the tenets of the Pact ethos: human readability. Such programs would necessarily be more difficult to read as an untyped core language. While not as bad as raw EVM or Bitcoin bytecode, the resulting programs would be less readable on-chain than otherwise. Additionally, having this interpreter live as a smart contract or on a parathread would not exercise the full breadth of services offered by a full Pact Service, such as dry-runs and polling, leaving these features up to the parachain or parathread operator.

Meanwhile, the primary advantage of Core Pact is that it can run on any parachain, not only a specific Pact Service parachain. Core Pact would be a feature available to any Polkadot smart contract.

## Motivation

The outstanding motivation at time of writing is to ensure that Pact integration with the Polkadot platform is as robust and full-featured as possible.

## Backwards Compatibility

N/A

## Specification

N/A

## References
* Polkadot: <https://wiki.polkadot.network>
* Parachains: <https://wiki.polkadot.network/docs/en/learn-parachains>
* Polkadot Smart Contracts: <https://wiki.polkadot.network/docs/en/build-smart-contracts>
* Kadenamint: <https://github.com/kadena-io/kadenamint>
* FOAM’s Kepler ABCI bindings: <https://blog.foam.space/kepler-release-announcement-3821bbd0dbd5>