265 – Ethereum und Solidity
| Rate/Vote |    (average: 3.90) Loading... |
Gast: Christian Reitwiessner Host: Markus Völter Shownoter: Jochen Spalding
Nach der Einführung in Blockchains und Smart Contracts in der letzten Episode betrachten wir nun eine konkrete Blockchain-Technologie im Detail: Ethereum, sowie die darauf meistgenutze Programmiersprache Solidity. Unser Gast ist Christian Reitwiessner, der Lead Developer von Solidity. Wir besprechen die Grundlagen von Ethereum, wie die Blockvalidierung funktioniert, die Ethereum Virtual Machine und Gas, die Grundlagen von Solidity, einige Ideen wie sich Solidity weiterentwickeln könnte, sowie alternative Sprachen wie bspw. Viper. Wir betrachten auch einige der Exploits und diskutieren, was man daraus lernen kann bzw. gelernt hat.
Thematisch verwandte Episoden als Hintergrund:
Vorstellung des Gastes Christian Reitwießner
00:01:48Dr. Christian Reitwießner | Dr. Christian Reitwießner auf Twitter | Julius-Maximilians-Universität Würzburg | P-NP-Problem | Ethereum | Dezentrale P2P Netzwerke | Turing-Vollständigkeit | Solidity | Ethereum Project | Ethereum Foundation | Vitalik Buterin | 2014 Token sale Ethereum | ICO
Wie Funktioniert Ethereum?
00:06:08Ether | Bitcoin | Nick Szabo | Atomare Operation | Ethereum Virtual Machine | WebAssembly | Merkle Tree | Key Value Store | Gas | Block Gas Limit | Multisig | General Purpose Language | Special Purpose Language (DSL)
Solidity
00:39:07Statische Typisierung | For-Schleife | While-Schleife | Zuweisung | Type conversion | Singleton | TX Origin & MSG Sender | COMEFROM Statement | SHA256 | Require & Assert | Automatisierte/formale Verifikation | Z3 | Arithmetischer Überlauf | OP code | OP Codes im Ethereum Netzwerk | Bytecode | Composite pattern | CBMC | Coq | Lem-Ethereum | Lem | IDE | Unit Testing | Testnets im Ethereum Netzwerk | Von-Neumann-Architektur | CALL, CALLCODE and DELEGATECALL | Serpent
Welche weiteren Sprachen gibt es / sind in Arbeit?
01:36:44Viper | Bamboo | Babbage | LabVIEW | The incredible Machine
Skalierbarkeit
01:50:21POW (Proof of Work) | POS (Proof of Stake) | Consensus finding | Sybil-Attacke | Fork | Casper | Sharding | Raiden | Lightning (Bitcoin) | Nonce | Swarm Distributed Storage
This website uses cookies to improve your experience. We'll assume you're ok with this.
Diese Webseite verwendet Cookies. Wir gehen davon aus, dass das für Sie/Dich in Ordnung ist.
Jetzt geht es da dauernd um Zustände und Verifikation. Wo kommt das denn noch vor? Bei Hardware! Guckt euch mal eine Hardwarebeschreibungssprache wie VHDL an, da baut man auch Zustandsmaschinen. Vor allem sind HDLs auch für Nichtprogrammierer einfach zu verstehen. Es passiert einfach alles immer (Kombinatorik) und getaktete Beschreibungen mit Speicherelementen passieren mit einer Taktflanke. Es ist sogar für Leute die Hardware beschreiben, wenn diese vorher schon programmieren können weil das unterschiedliche Denkmodelle sind. In Hardware denken ist fast wie bei mechanik, man denkt ähnlich wie bei Zahnrädern die ineinander greifen und Dinge bewegen, genauso kann man bei Digitalschaltungen den Ablauf wunderbar auf Karopapier hinmalen und mit jedem Takt ein Kästchen weiterrücken und dort wieder seine 1en und 0en eintragen.
Den ganzen State kann man dann schön in der Simulation sehen wie eben Signale bei einem Logic-Analyzer.
Wenn man das jetzt so bauen würde, dann wäre das kein Programm sondern Hardware mit einem Ausgangszustand. Dafür gibt es Formate, sogenannte Netzlisten. Ausführen kann man die dann in Software, also im Simulator oder man packt das in ein FPGA. Was ist dann dieses Gas? Das kann man auf zwei Dinge aufteilen, einmal auf die Zeit die es laufen soll, also wieviele Takte abgearbeitet werden und dann noch in Logikelemente, also wieviele Multiplizierer, Logikverknüpfungen und Speicherelemente durch die beschriebene Hardware belegt werden. Am Ende hat man eine virtuelles unendlich großes FPGA auf dem Jeder seine Hardware laufen lassen kann. Er bezahlt für Taktzyklen und benutzte Ressourcen.
Hardwarebeschreibung sollte auch mächtig genug sein, man kann darin ja wieder CPUs beschreiben und dort beliebiges machen, dann aber nacheinander seriell im Gegensatz zur Hardware selber die parallel läuft.
Und weil Hardware teuer ist, und man ungerne Chips fertigen lässt die dann Fehler haben, wird eine Hardwarebeschreibung echt gut getestet und simuliert.
Ihr habt mich hier und da ganz schön angehängt. Aber finde gut dass es so Episoden gibt.
Bei Babbage musste ich am Smalltalk denken.
Ziemlich am Ende bei dem “Micropayment für E-Auto-Laden”-Beispiel musste ich schmunzeln. _Das_ Problem ist doch schon gelöst, bzw. aufgemacht: https://media.ccc.de/v/34c3-9092-ladeinfrastruktur_fur_elektroautos_ausbau_statt_sicherheit ;-)