@LiskHQ
Dazu hätte ich mal eine theoretische Frage.
Nehmen wir an, nach dem 21.03. kommen 1000 BTC zusammen.
Ich würde über meinen Account 10 Exchanges zu jeweils 20 BTC komplettiert haben.
Dann wären das ja diese 20%. Ihr würdet dies aber durch meine Account-Daten bzw. der E-Mail erkennen?
Würde ich hingegen 10 ICO-Accounts eröffnen und jeweils ein Deposit von 20 BTC tätigen, dann sieht die Sache doch schon anders aus.
Richtig. Der zweite Fall kann einfach nicht überprüft werden, ohne jeden einzelnen Teilnehmer nach dem Passport zu fragen.
Hey haggis, hatte dir ja versprochen noch heute Abend zu antworten.
1.) Nein, die Dapp selber wird nicht auf der Lisk Blockchain gespeichert. Bei Crypti ist es aktuell so, dass dafür entweder GitHub (Zentral) oder Sia (Dezentral) verwendet wird. Bei uns wird es so sein, dass zuerst einmal lediglich ein .zip Link (Zentral) zur Verfügung gestellt werden muss. (Kann von GitHub, deinem Server oder irgendwo sonst herkommen). Später wollen wir dann so schnell es geht IPFS (Dezentral) integrieren, damit es schön dezentral bleibt.
2.) Als wir das System damals designed haben mit Boris, wollten wir es zuerst genau so machen, wie du es beschrieben hast. Allerdings haben wir uns dagegen entschieden. Wenn wir einmal 1,000 und mehr Dapps/sidechains haben, die alle paar Stunden eine Transaktion schicken müssen zur Sicherung, dann skaliert unser System nicht. Wir hatten uns dann überlegt, dass die Sidechain Betreiber dies optional machen können. Kamen aber nie zu Implementierung, müssen uns noch überlegen ob wir das noch einfügen.
Aktuell sind Sidechains weitestgehend autonom. Eigene Delegates (i.e. Master Nodes) und eigenes Forging auf jeder Sidechain. Deswegen müssen wir später eine Art Marktplatz programmieren, auf der sich dann ganz simpel jeder für eine Sidechain eintragen lassen kann oder auch wieder austragen.
api.lisk.io wird so schnell es geht gefixt. Sorry. Bis jetzt alle regulären Lisk API calls, aber NICHT schön niedergeschrieben, hier:
https://github.com/LiskHQ/lisk-docs/blob/development/APIReference.mdDanke!
Dachte, ich schreibe die Fragen doch gleich hier noch mit rein. Dürfte ja auch für andere interessant sein.
Zu 1) Wenn eine Dapp per zip (oder sonstwie) verteilt wird, wie wird dann sichergestellt, dass sie vom Master Node nicht manipuliert wird? Nur durch Reputation? Wir haben ja bspw. im Bitcoin Core Team gesehen, dass auch innerhalb einer Gruppe mit hoher Reputation es im Laufe der Zeit zu Verwürfnissen kommen kann. Wenn dann der Betreiber einer Sidechain einem Master Node nicht rechtzeitig den Stecker zieht, könnte dieser unter Umständen falsche Ergebnisse liefern?
Oder werden die Ergebnisse mehrerer Nodes miteinander verglichen (= x-fache Arbeit) und über das Ergebnis dann abgestimmt?
Zu 2) Irgendwelche Absicherungen durch die Bitcoin Blockchain wäre sicher praktisch. Ich glaube es war IOTA, die über mehrere Blöcke der Sidechain einen "Megahash" bilden und den dann in die BTC Chain schreiben. Vlt kann man sich davon ja inspirieren lassen
1.) Richtig, aktuell kann die Dapp geändert werden. Lisk ist nicht "trustless" wie z.B. Ethereum es ist. Lies dir
dieses Interview bei der Frage "how will you compete against the giant of smart contracts" durch. Wobei wir das sicherlich mit hashes und einem richtigen Update Mechanismus einbauen können.
Aktuell bietet Lisk dezentrale Applikationen in einem Webseiten Format an. Das heißt du kannst einen Exchange programmieren, der dezentral und auf einer Sidechain läuft. Es ist aber nicht zu 100% selbstverständlich, dass diese App auch sicher ist, nur weil sie früher einmal sicher war. Wir werden sehr viel darüber nachdenken und etwas implementieren, was es ermöglicht zu checken ob eine Dapp verändert wurde oder nicht. Allerdings muss irgendwo das Vertrauen anfangen, dass heißt der Dapp Programmierer wird neue Updates rauspushen können. Wenn er was negatives einbaut, sehen dass die Menschen und können das Projekt forken, basierend auf einem älteren Update. Das setzt vor raus, dass die Dapp open source ist und nicht unkenntlich gemacht wurde.
2.) Dem stimme ich dir zu. Ich kenne David und CfB, werde das white paper mal lesen und gegebenenfalls nachfragen sobald wir released sind.