von hier: https://bitcointalk.org/index.php?topic=5313399.new#new
Link zum Coin: http://wallstreetbets-crypto-coin.com/
WSB-Coin Bericht
Einleitung
Dieser Bericht beschreibt die Erkenntnisse die das Team während der Eintwicklung eines Token Projektes für die Ethereum Blockchain gesammelt hat.
Dabei wird auf eventuelle Probleme eingegangen und Stellung zu typischen Vorgehensweisen genommen. Ziel und Sinn der Arbeit ist die Einarbeitung des Teams in die Blockchain-Thematik aus Entwickler Sicht.
Tooling
Die Entwicklung einer dApp für das ETH-Netzwerk bietet eine große Auswahl an Tools die einem bei Projektbetrieb unterstützen. ConsenSys hat eine Liste an Frameworks, IDEs und anderen Tools zusammengestellt:
https://github.com/ConsenSys/ethereum-developer-tools-list#developing-smart-contracts
Weil das Lernziel der Fokus des Projektes ist haben wir uns für die populärsten Toolings entschieden, da für diese bereits eine Vielzahl an Resourcen zur Verfügung stehen:
https://www.trufflesuite.com/ganache
Aufsetzen einer lokalen Ethereum Blockchain für:
- Laufen von Tests
- Ausführen von Commands
- Inspizieren von States
CLI Version: https://github.com/trufflesuite/ganache-cli
https://www.trufflesuite.com/truffle
- Smart Contract Kompilierung, linking, deployment und binary management
- Automatisiertes Testen von Contracts mit Mocha und Chai
- Konfigurierbare build pipeline
- Scriptable deployment und migrations
- Interaktive Console für direkte Kommunikation mit Contracts
Quickstart:
Installation: npm install truffle -g
https://github.com/trufflesuite/truffle
Interagieren mit Contracts:
https://www.trufflesuite.com/docs/truffle/getting-started/interacting-with-your-contracts
Visual Studio Code
Plugin: solidity (identifier: juanblanco.solidity)
Go-To IDE mit vielen Plugins.
Token-Standards
Der Smart Contract soll eine fungible Token darstellen.
Die Ethereum Community hat für diese mehrere Standards definiert die sich in ihrer Anwendung leicht bis grundsätzlich unterscheiden.
Durch Standards soll Interoperabilität und einfache Integrierbarkeit gewährleistet werden, so können exchanges mit wenig Aufwand ein weiteres ERC20-Token zu ihrem bestehenden Sortiment hinzufügen.
Es wird hierbei nur ein weiterer interner Eintrag mit Verweis auf die Contract Adresse von Seiten des Exchanges benötigt.
ERC-20:
-ERC20 Tokens laufen auf der Ethereum Blockchain (gespeichert auf ETH Adresse, über ETH Transaktionen gesendet und nutzen ETH für Transaktionsgebühren)
-Viele ICOs nutzen ERC20
-Standart vereinfacht den Exchange von ERC20 Tokens untereinander
-zb lassen sich verschiedene ERC20 Tokens ohne großen Aufwand in Platformen wie Wallets und Exchanges integrieren
ERC-223:
-ERC-20 Token mit erweiteter Funktionalität
-Wenn ERC-20 Tokens zu einem Smart Contract gesendet werden die nicht mit ERC-20 Standart kompatibel ist, gehen die Tokens für immer verloren.
-ERC-223 hat daher eine tokenFallback Methode die versichert, dass Tokens nur zu Contracts geschickt werden die ausreichend Funktionalität mitführen
ERC-777:
-ERC-20 Token mit erweiteter Funktionalität
-Gibt dem Nutzer mehr kontrolle über ihre Tokens
-Definiert erweiterte Features um bsp. Tokens im Auftrag einer anderen Person senden zu können.
ERC-1155:
-Ein Interface welches Smarts Contracts erlaubt verschiedene Typen von Tokens zu managen
-Die untertützten Tokens können fungible und non-fungible sein (zb. ERC-20 und ERC-721)
ERC-1337:
-Token Standard für Subscriptions auf der Ethereum Blockchain
-Fokus auf Interoperabilität um Wallets zu ermöglichen Contracts mit wiederkehrendende Zahlungen zu signieren
Wir haben uns für den basic ERC20-Standard entschieden.
Hauptgrund hierfür ist die schnelle und unkomplizierte Anbindung an Exchanges wie z.B. UniSwap.
Best Practices – Security Considerations
Die Entwicklung einer dApp unterscheidet sich durch das dezentrale Netzwerk grundsätzlich von
klassischer Programmierung. Das neue Ecosystem bietet neue Angriffvektoren über die man sich im klaren sein sollte. Da Contracts von Grund aus immutable sind und dadurch das Updaten einer dApp ohne Vorbereitung nicht einfach so möglich ist, ist ein Fehler auf dem Netzwerk umso kritischer. Daher hat die Community über die Jahre hinweg Best Practices und Security Concerns für Design-
Patterns und Solidity Code gesammelt:
https://github.com/fravoll/solidity-patterns
https://docs.soliditylang.org/en/develop/security-considerations.html
Zusätzlich haben Unternehmen wie OpenZeppelin Standard-Contracts gründlich prüfen lassen:
https://openzeppelin.com/contracts/
Diese Praktiken und getesten Contracts sollten immer als Abgleich zu Rate gezogen werden.
Unit Tests - Testnet
Durch die sicherheitskritischen Aspekte sollte eine 100% Testcoverage gegeben sein. Die gängigen Sicherheitskriterien sollten durch eine Audit-Checklist
https://github.com/cryptofinlabs/audit-checklist
Das Truffle Framework implementiert Mocha/Chai als Testumgebung die das Schreiben von Unit-Tests in JavaScript ermöglicht:
https://www.trufflesuite.com/docs/truffle/testing/writing-tests-in-javascript
Wenn lokal nach Audit keine Auffälligkeiten aufgetreten sind ist das Token auf einem Testnetz zu
deployen. Testnets arbeiten genauso wie das Mainnet, mit den Unterschied dass ETH-Balance über sogenannte
Faucets ausgeschüttet werden. Diese Faucets haben je nach Testnet verschiedene Bedingungen die folgend aufgelistet sind:
Kovan: Verlinkung über GitHub erforderlich; https://faucet.kovan.network/
Rinkeby: Erfordert einen Social Media Post; https://faucet.rinkeby.io/
Ropsten: Keine Bedingung, Test-ETH sind aber nach Wochen immernoch nicht vorhanden; https://faucet.ropsten.be/
Deploy auf Mainnet
Sollten keine offenen Probleme bestehen ist schlussendlich ein deploy auf dem Mainnet möglich.
Hier ist zu beachten dass genügend Funds auf dem Konto zur Verfügung stehen um die Gas-Kosten für
Deploy und Transaktionen zu decken.
Unter Umständen kann nämlich hier das Erstellen des Contracts wegen ungenügend Funds fehlschlagen,
die Kosten für Gas werden trotzdem abgehoben.
Es sollte auch vorzeitig ein Budget für das Projekt beschlossen sein worden um zu überprüfen ob dieses
auch ausreichend für einen Deploy ist.
Das Ethereum Netzwerk ist stark ausgereizt und da der Kurs aktuell drückt sind die Kosten für Aktionen
auf dem Netzwerk entsprechend kostenspielig.
Dies war die Kostenberechnung für unser Projekt:
standart gwei/gas: 176
BCH Swap: ?
Deploy: 1.377.169 * 176 GWEI = 242.381.744 GWEI = 0.242381744 ETH
initial Supply: 133.072 * 176 GWEI = 23.420.672 GWEI = 0.023420672 ETH
Uniswap Approve: 48.889 * 176 GWEI = 8.604.464 GWEI = 0.008604464 ETH
Uniswap Liquidity: 2.705.679 * 176 GWEI = 476.199.504 GWEI = 0.476199504 ETH
Gesamt: 0.750606384 ETH = 1008.59€ (exklusive BCH swap)
mit 115 gwei/gas: 4264809 * 115 GWEI = 490453035 GWEI = 0.490453035 ETH = EUR 659.02€ (exklusive BCH swap)
Besonders teuer wird es wenn man das Token manuell an die Nutzer verteilen möchte.
Mit jeder Transaktion sind Tx-Kosten zu zahlen, bei aktuellem Stand liegt der Wert bei 22.05$.
Fazit
Smart Contract Entwicklung ist grundliegend einfach, der Einstieg in die Thematik erfordert aber ein
Umdenken was diesen Prozess betrifft.
Risikomanagement steht hier allen vorran.
Projektansprüche müssen klar definiert sein um zukünftige Problem frühzeitig erkennen zu können.
Bei unserem Projekt ist erst zum Schluss aufgefallen dass die Kosten zu hoch für unseren Nutzen sind,
dies hätte man bei genauerer Betrachtung früher herrausfinden können.