Title: ETH Token erstellen Programmieren und auf den Markt bringen. Post by: romanengel on February 11, 2021, 06:03:38 PM Anbei dies Zusammen Fassung zu unserem Projekt:
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 (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 (https://www.trufflesuite.com/ganache) Aufsetzen einer lokalen Ethereum Blockchain für:
CLI Version: https://github.com/trufflesuite/ganache-cli (https://github.com/trufflesuite/ganache-cli) https://www.trufflesuite.com/truffle (https://www.trufflesuite.com/truffle)
Quickstart: Installation: npm install truffle -g https://github.com/trufflesuite/truffle (https://github.com/trufflesuite/truffle) Interagieren mit Contracts: https://www.trufflesuite.com/docs/truffle/getting-started/interacting-with-your-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://github.com/fravoll/solidity-patterns) https://docs.soliditylang.org/en/develop/security-considerations.html (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/ (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 (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 (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. |