2nd layer scaling and economic security analysis

Transcript

1. 2nd Layer Scaling and Economic Security Analysis Cryptoeconomics Lab - Sg
2. Implementation Security Formally Verifiable Smart Contract - smart contract layer security (Bamboo, LLLL, k-lang derivatives) Multi Language Client Implementation - Some of vulnerability and performance degradation may come from backword incompatible upgrade of programming language (e.g. Ethereum’s geth syncing degradation) (Almost) Formally Verifiable Protocols - Plasma MoreVP (Exitgame’s semi-formal verification) In this deck, I don’t dig for this category
3. Some other kind of software securities certainly exist
4. Economic Security DoS/Sybil vector mitigations - Tezos’s zero fee account creation DoS - ETH’s Gas model - Plasma’s exit bond - Permissionless PoW/PoS’s participation cost Fund Security - Plasma’s fund safety is trustless over the Operator Stability Security - Plasma’s stable execution is trusted over the Operator
5. Anti Patterns Federated Withdrawal - Permissioned fund transfer is gamable at large scale - When suddenly sidechain operator(s) stop execution, how do you save your fund? - “Asking the malicious operator” shall not work - “Asking the 1st layer” is the current best practice Proof-of-Burn - Burn your childchain fund by making 2nd layer Tx (thanks of the Operator’s server) - Submit the burnProof to 1st layer contract for withdrawal - When the operator is malicious, this burning process would be suspended
6. Pro Tips - If you deal with small amount of deposits on 2nd layer, trusted entity doesn’t matter. And you can deal with it your own trust (e.g. Smaller deposits than 2years expected profit of the operator … >2years profit might incentivise gaming) - But in that use cases, you are not levaraging your trust. You can do it better by RDBMS. - If you believe in “trust-minimization” phenomenon is happening in this world, you need yo rethink what you are betting. - These above doesn’t meant to be insecure. But just different security strength from 1st layer. Depends on usecases, you must choose appropreate tools. And informed concent to actual user is very important to avoid unintentional accident.
7. Pro Tips 2 - If you owe the responsibility of the customers’ fund security, you need to be registered entity of that country in many cases. - When the financially licensed company tries to deal with public blockchain, they firstly come up with “Why is it public? We already have enough trust to deal with this world! Just let me copy your chain, or bring some Hyperledgers!” - Fundamentaly trustless property is not needed for well- trusted companies. And these two things are conflicted idea.
8. Many kind of trust - If you trust someone others regarding “Please don’t lose my money.”, it’ll be lost unless the entity is legally licensed (tips: it works only in well-developed society). - If you trust someone others to run the 2nd layer chain stable, but you can verify/convince you can secure your money by only interacting with 1st layer, it can be called “2nd layer scaling solutions”. - Otherwise, it is just trusted, weak-security, permissioned, psuedo-interoperable, independent chain.
9. As trust minimized, we don’t trust the person who made the app. All investment to the crypto market would accumulated to the free open source software community. Transaction speed/cost getting much more faster/ cheaper. These all technologies are accessible for everyone in this world. We all can start spontaneous innovation autonomously. What a good world!
10. Have a sensibility, stop closed source, stop trusted app.