KIP-0003: Polkadot Integration

[emilypi]

See https://github.com/kadena-io/KIPs/blob/kip-0003/kip-0003.md.

---

• To see the specific tasks where the Asana app for GitHub is being used, see below:
  • https://app.asana.com/0/0/1208668844268824

[emilypi]

A question from Robert Hambrock:

as already mentioned during our call in May, can you make this ["there should be no sizing issues with a Polkadot integration"] assertion concrete?

Response from Emily Pillmore:

Yeah, I can thanks for asking! So, the main point about sizing here is that. by adding the extra compilation step for this "minimal Pact", we can shunt most of the responsibility for checking program correctness to the typechecker unlike the usual Pact workflow which checks many invariants and types at runtime. This means the core language that the interpreter needs to execute is necessarily less complicated and can be bulldozed through using less complex machinery. For example, a CEK machine for a smaller language could be implemented in only a few hundred lines and require nothing else. I can wrote this one up for a sublanguage of Pact in 100 lines: https://gist.github.com/emilypi/40d69e86794f8557c5c3950b40662ce7. This is about as concrete as we can get at this point, but experience and subject matter expertise is telling us that this won't end up a very large interpreter at all.

[emilypi]

Another question from Robert Hambrock:

what is the target audience for this feature [to make sure code on chain is human readable for authors and users alike]? If you doubt a smart contract's veracity (only relevant for users, not authors), you'll obtain its source code and thus verify its logic in its most humanly-intelligible form (unless the claim is that the deserialized syntax tree is as intelligible as the original typed source) and subsequently verify the authenticity of the deployed contract via a deterministic build.

Correct me if there are caveats, but if you only have access to the intermediate representation, you cannot trust any of the soundness guarantees of typed Pact that are no longer explicit in the intermediary untyped deserialized syntax tree that Pact is compiled down to.

And if you obtain the source code for the smart contract (which you should before interacting with it) - you don't have to, since you can simply verify these soundness guarantees by compiling the source down to hard-to-humanly-parse WASM (the intelligibility of which is consequently irrelevant).

Response from Emily Pillmore:

The target audience for this interpreter is smart contract authors, while the target audience for Pact Service is the broader smart contract author and user base. You're right that you do lose some information in the case of the minimized syntax tree. While the new AST would be pretty print-able and human readable, you would have to have a bit more trust than in the invariants of the code than in the typed AST. I think the statement "you can't trust any of the soundness guarantees" is a bit off. You can trust the soundness of program because it would be correct by construction. But it would not be a human-readible feature, since you're erasing types and some of the information that would allow you to verify for yourself that a program is sound. The idea here is to bake that information into the compiler for this syntax tree. In the end, I agree with your final point - yes, the fully typed source is your best bet for understanding the code. But legibility does not have to be a zero-sum game; a partially legible tree is still better than raw bytecode!

[emilypi]

Regarding the recent addition of Module References into Pact, I propose the following as an addition to the spec:

1. A separate continuation mark must be considered during execution to trigger the lookup of module references. These can be written as a flag which triggers a query to the Pact service database to resolve module references. Then, the module reference terms must then be dynamically loaded and compiled to Pact Core on demand. This mirrors what we do in Pact, only, with the additional step of resolving to Pact Core through dynamically.

[kcelestinomaria]

Hello there, I am working on a Substrate chain, independent for now but future parachain. I want to know if I can have Pact on the chain I am working on. How did the research to include Pact onto Polkadot go? I intend to have Pact as a first class smart contracts language on my chain through this work, how can I make it happen? Thank you.

[kcelestinomaria]

Also, how well does Pact minimize complexity for developers writing dapps? Does the developer have to interact with consensus and networking?

[emilypi]

Hi @kcelestinomaria - this is currently still in RnD, but the research tells me this should work just fine if we get the go ahead from Polkadot. From a priority standpoint, I would love to see this out within the year, but alot of our work is dependent on whether Web3 Foundation signs off on the idea! I've delivered the preliminary research paper to them, and we're waiting to hear back. People can help by harassing them every chance they get 😉

Also, how well does Pact minimize complexity for developers writing dapps? Does the developer have to interact with consensus and networking?

As a rule, Pact smart contract authors never have to interact with consensus or networking. The service that runs the Pact transaction layer only requires a little integration on the implementation side of things, but never on the part of people doing the contract development. From the smart contract author's perspective, It Just Works (tm).

[Sambhavjain975]

Will Kadena be participating in the perachain auction for KadenaDOT?