Polkadot SF Meetup Notes

Ali Sheikh
4 min readAug 13, 2018

A couple of days ago I attended the Polkadot Meetup in San Francisco, wanted to share my notes from the meeting in case people weren’t able to make it.

I arrived right at 7pm because I had heard quite a bit about Polkadot and knew that this meet-up would be packed and epic, it did not disappoint.

The following are notes from the meeting — I tried to capture what I could but couldn’t capture everything given the interesting talks.

Speaker 1: Peter Czaban, Web3 Foundation

>Web3 Foundation: WEB3 is the vision of the server-less internet, the decentralized web. Web3 Foundation has commissioned Parity Technologies has been to build the Polkadot network.

Parity Technologies: building software based on new peer-to-peer technology to power this future decentralized web.

1/ Framework for building decentralized applications

a) Multi-user applications that conform to certain constraints - No user is privileged over the other users

b) Data distribution protocols

c) Transient messaging

d) Second layer protocols API languages and browsers

e) Replicated state machines

2/ Substrate crucial role

a) Parity_substrate — a framework for creating cryptocurrencies and other decentralised systems using the latest research in blockchain technology

b) Want to reduce the overhead to build them

c) Substrate enables the easy implementation of new blockchains

d) Relies on P2P

e) Parity tries to use state of the art consensus

3/ Missing piece

a) All secure

b) Communicate with each other

c) All run on a single user device

4/ Polkadot — protocol that enables different state machines to communicate with each other and share security while using them from one node

a) Easier experimentation

b) Adaptation through governance

5/ Why do we need another system (i.e. vs. Bitcoin / Ethereum)

a) One Size doesn’t fit all

b) Different projects need different designs, different state machine designs

c) State machine is different

d) Enterprise needs aren’t met — public blockchains don’t meet the (1) permissioning and (2) confidentiality for businesses

e) Facing a fragmented landscape

f) Current generation of blockchains cannot talk to each other without going through a centralized service which defeats process of blockchain

6/ Why is Polkadot different

a) Built for Interoperability

b) Connect chains with distinct state machines and consensus

c) Support past, present, and future (vs. i.e. Ethereum, Bitcoin; Polkadot is flexible enough to absorb new innovation i.e. on the consensus layer)

d) Public and private running in same network

7/ Thinking beyond tokens

a) Interoperability of token is clearly desirable

b) Arbitrary message passing is a superset and more valuable for innovation

c) Interoperability framework

8/ Co-securing the community

a) Connecting blockchains is hard, securing them is even harder

b) Blockchains naturally compete with each other over security resources

c) Polkadot lets chains pool security resources, competition turns into rules based cooperation

d) Let these chains pool security — vs. competing

Security Resources

9/ Scaling blockchain horizontally — side effect of interoperability

a) Multiple chains running in parallel

b) Increasing throughput by parallelzing transactions

10/ 10,000 Foot View

a) Relay Chains: Coordinates consensus and transaction delivery between chains

b) Parachains: Constituent blockchains which gather and process transactions

c) Bridges: Link to blockchains with their own consensus such as Ethereum

— — — — — — — — — — — — — -

Fredrik Harrysson — Breakdown

1/ Design Principles

a) Heterogeneous: support an ecosystem of diverse and complementary utilities

b) Scalable: scalable on-chain and off-chain with an ultra-efficient root layer

c) Secure: define rigorous and formal models of security of the system, protected with economic games

2/ Explaining Parachains

a) Validity Function: WebAssembly stored on-chain in the parachain registry

b) Collator Node: Creates “candidate” blocks that satisfy the validity function

c) Message Queues: candidates must also process incoming and produce outgoing messages

3/ Where are we now?

a) PoC-1: Governance, staking, basic UI, and forkless upgrades

b) PoC-2: “co-finalization” of non-communicating parachains and basic light client

4/ What’s Next?

a) PoC-3: Implementation of hybrid consensus described in these slides

b) PoC-4: Implementation of Validity / Availability game

c) In Parallel: developer tools for parachains

5/ Parity Substrate

>Bitcoin, Ethereum, [rewriting everything from scratch] no need to

>When we build a website, enginx or apache no need to build these from scratch but we do this in blockchain world

a) Customizable framework

b) Secure, fast, light client-first

c) A better way to upgrade shared protocols, decisions compliant with the defined governance process are automatically followed by client

6/ Parity Substrate Goals

a) Adaptability

b) First-class light-client

c) Binding governance

d) On-ramp for parachains

e) Foundation for relaychain

7/ Other info on Parity Substrate

a) Architected on WebAssembly

b) Build on libp2p

c) Rust-based primary impl.

d) Javascript secondary impl.

Hope these notes were helpful and please excuse any typos / errors. Any input would be much appreciated!

If these notes were helpful and you are feeling generous :)

BTC: 3PKSq6m1yCze3pehW2iShqpjvGDhGQfBB8

ETH: 0xaA2923BE66F3c6c88394D7Fa6938Bd17a967Ad26

--

--

Ali Sheikh

Crescat scientia; vita excolatur ◎ Crypto mad scientist ◎ Analytics @ Flexport ◎ MS Computer Science @penn ◎ Econ @Uchicago . https://medium.com/@alisheikh