Polkadot Dallas meetup 1st event
---


https://www.meetup.com/Polkadot-Dallas/
_10/18/20 2pm CDT_

## Intro

DOT (2) random raffle (members of first meetup) install PolkaWallet

Question for audience: "What is your experience with crypto? Are you an investor, developer, just curious?"

What is Polkadot
- Gavin Wood
- Co-founder / CTO of Ethereum, investor of Solidity
- Raised funds through ICO for Polkadot in 2017
- Canary network Kusama launched in 2019
- Main net launched in 2020
- Next generation blockchain of blockchains
- Parachains and interoperability
- Ethereum first, then eventually Bitcoin
- Substrate
- [Polka Projects](https://www.polkaproject.com/)

## Substrate // Dan

1) what is substrate?
- framework to build blockchain networks
- what polkadot and kusama use
- easy to create parachians
- modularized to pulg-n-play features for novel chains with specific effecienies
- upgradable runtime: no need for hard forks to update/fix bugs for the network
- Why use it? what is it for?
2) parachains
- examples of projects
- https://twitter.com/MoonbeamNetwork
-
- cross chain interoperability
3) future...
- smart contracts in `ink!`
-
5) resources
- https://substrate.dev -- go over flow of the site to get started
- Element chat for support
- SHILL EVENT: Sub0 (substrate devs conf) on 10/15/20 https://sub0.parity.io/

polkadot is a network which allows running parachains. Polkadot's reference implementation (by parity) is based off a substrate. To provide a function of runtime upgrades the logic of the chain is encoded in wasm. We refer to that wasm - Substrate Runtime or sometimes as Polkadot Runtime.

Then

A Parachain Validation Function uses wasm to encode the state transition rules of a parachain. That's another wasm environment and at the moment it is extremely similar to a Substrate Runtime excluding some differences

Then

Substrate Runtime can access Substrate sandboxing facilities. This capability allows a Substrate Runtime to instantiate an isolated wasm module which is completely under control of the Substrate Runtime. This is what powers the contracts module (it's informally known as Seal, FWIW, ink! is a smart-contract language, hopefully among of many, that targets Seal-flavoured wasm). By extension, this functionality is available within a PVF environment and thus a parachain can use this functionality to create a smart-contract parachain.

However, it is important to emphasize that the Polkadot Runtime, i.e. the relay chain, does NOT provide any smart-contract functionality. It's up to parachains.

With all of that, I can answer your question.

So for PVF and Substrate Runtimes we use the Substrate Runtime Execution Engine. At the moment that is backed by wasmtime or wasmi (in cli are known as compiled and interpreted).

Then for sandboxing capability we have to do things differently. Since it was designed for contracts use-case in mind and in such an environment anyone can deploy a contract with any code it likes. The problem is that many execution engines that are based on optimizing compilers might be vulnerable for so called JIT bombs - basically such code targets algorithmical inefficiencies, requiring disproportional time or memory to compile such code.

Therefore, we have to use a special kind of compiler that can chug along any code that you throw at it. The price for that is code for less quality.

Note how I substituted execution engine to compiler in the writing above. That's because wasmtime should be capable for working in both modes. At least, when lightbeam, a linear-pass compiler, lands there. 

Right now, we only have wasmi as an execution engine for sandbox though. But the integration should be in process as we speak