30 Blockchain-platform technische factoren

blog 1NieuwsOntwikkelaarsEnterpriseBlockchain ExplainedEvenementen en conferentiesPersNieuwsbrieven

Abonneer op onze nieuwsbrief.

E-mailadres

Wij respecteren uw privacy

HomeBlogEnterprise Blockchain

30 Blockchain-platform technische factoren

Belangrijke technische aspecten waarmee u rekening moet houden bij het kiezen van een blockchain-platform voor uw zakelijke gebruikssituatie. By Clemens Wan 5 maart 2020 Gepost op 5 maart 2020

2

Clemens Wan is Solution Architect bij ConsenSys. Hij schrijft lijsten van 30 seelemons.com.

Als uw keuze voor een blockchain-platform minder te maken heeft met de bedrijfsfactoren (zie 30 Blockchain Platform-bedrijfsfactoren), dan bekijkt u misschien enkele van de technische aspecten voor uw use-case. Deze lijst van 30 behandelt blockchain-specifieke vragen die bij het doorlichten van een platform voorop moeten staan.

DevOps / Netwerk / Implementatie / Protocol

  1. Flexibiliteit voor de inzet van Blockchain-lagen – Heeft het platform een ​​openbare instantie? Toegestaan? Privaat? Hybride?
  2. Optimaal aantal knooppunten – Hoeveel knooppunten zijn er nodig om het netwerk te ondersteunen? Een voor elk lid? Kan ik communiceren met het netwerk zonder een knooppunt uit te voeren?
  3. Containerisatie – Kan het platform worden gekoppeld en ingezet via Kubernetes?
  4. Netwerk-identiteitsbeheerlaag – Hoe worden machtigingen voor knooppunten en individuen beheerd? Zijn er beperkingen voor supergebruikers? Is er een bronnetwerkkaart van alle partijen in het netwerk (bijvoorbeeld DNS-achtige service – ENS in Ethereum)?
  5. Consensusmechanisme – Is het systeem gebaseerd op Proof of Work? Bewijs van inzet? Bewijs van autoriteit? Bewijs van verstreken tijd? Dit wordt waarschijnlijk bepaald door de governance-instellingen en entiteiten op basis van wat het meest effectief is voor uw use-case.
  6. Berichten tussen organisaties – Zijn er aparte lagen voor privéberichten? Is dit op AMQP gebaseerd? RabbitMQ? XMPP? Beveiligde Scuttlebutt?
  7. Methodologie voor transactieverwerking – Welke volgorde van activiteiten vindt plaats in termen van transactieverwerking? Wanneer bestelt, valideert en voert het protocol de transacties uit? In Ethereum worden TX’s verzonden naar validerende knooppunten die bestellen / valideren voordat het “juiste” blok wordt uitgevoerd en gedistribueerd. In Corda worden TX’s individueel gevalideerd door de noodzaak om knooppunten te kennen via het Flow Framework totdat het wordt ondertekend en opnieuw wordt verspreid door de notaris.
  8. Cryptografie – Welke bibliotheken worden gebruikt en ondersteund door de hashes en handtekeningen? (bijv. secp256k1 voor Ethereum)
  9. Insteekbaarheid van cryptografie – Kunnen specifieke knooppunten ervoor kiezen om een ​​andere cryptobibliotheek te gebruiken op basis van hun regionale beveiligingsregels? (bijv. NIST-conformiteit)
  10. Technieken voor het delen van bestanden – Elk digitaal activum moet op de een of andere manier wettelijk verankerd zijn via de organisatie die het in bewaring houdt of het juridische document / proza ​​waarnaar in de code wordt verwezen. Hoe worden bestanden gedeeld tussen organisaties met het platform? Worden ze op hetzelfde platform opgeslagen? Worden ze op dezelfde manier geback-upt??
  11. Juridische verankering – Is er ingebouwd juridisch proza ​​of implementatie van juridische documenten (bijv.OpenLaw) binnen het protocol?
  12. Fraudebestendig versus fraudebestendig – Kan iemand uw lokale knooppuntstatus en zijn geschiedenis wijzigen? Als op de een of andere manier een transactie of status zou worden verwijderd, zou dit er dan voor zorgen dat alles niet synchroon loopt? Kunnen de historische gegevens waarnaar wordt verwezen worden gewijzigd of verwijderd en overeengekomen door alle partijen??
  13. Transactieherstel – Hoe herstelt een node de transacties? Als uw transacties niet volledig naar alle partijen worden gedistribueerd, wat zijn dan de mechanismen om de laatste overeengekomen versie te downloaden?
  14. DAO-mogelijkheid – Zijn er voorbeelden van dapps die de bestuursverantwoordelijkheid abstraheren? Dit kan handig zijn om het netwerk te hergebruiken om de stemming en het bestuur te behouden.

Ervaring met ontwikkelaars / Top of Stack-applicaties

  1. Toepassingsverantwoordelijkheid – Waar moet u zich zorgen over maken wanneer u uw top of stack-applicatie (dapp) bouwt? Moet je je eigen node hosten? Bent u ook verantwoordelijk voor het implementeren van de bijbehorende webservers en interfaces van de dapp? Hoe betalen uw gebruikers voor uw aanvraag??
  2. Dapp-laagimplementatie – Hoe worden slimme contracten in het netwerk geïmplementeerd op basis van machtigingen? Door een persoon (bijv. Adres op de witte lijst)? Door een knooppunt (bijvoorbeeld de identiteit van LEI)? Door een geregistreerde entiteit (bijv. Zakelijk netwerk toegevoegd aan het netwerk)? Door de infrastructuurprovider (bijv.Kaleido Marketplace)? Heeft u machtigingen op knooppuntniveau nodig om te implementeren?
  3. Slimme contracttalen – In welke taal is het slimme contract geschreven? Is het getest? Heeft het een goede gemeenschap?
  4. Slimme contractbibliotheken en standaarden – Zijn er overeengekomen veilige bibliotheken / functies (bijv.OpenZeppelin) die worden onderhouden en gecontroleerd? Zijn er algemeen aanvaarde implementaties van functies die zijn opgerold tot standaarden (bijv.ERC-20, ERC-721, enz.)?
  5. Slimme contractupgrade – Hoe worden applicaties bijgewerkt? Zijn er goed gedefinieerde upgradepatronen voor de slimme contractcode?
  6. Toegang tot referentie- en marktgegevens – Welke beschikbare orakels kunnen binnen het netwerk worden opgeroepen om de nodige informatie te ontvangen om een ​​geactiveerde actie uit te voeren?
  7. Aanbevolen identiteitsbeheer van individuen – Staan de publieke / private sleutelparen en adressen er van nature op dat individuen hun eigen sleutels onderhouden? Of veronderstelt dit realistisch dat tussenpersonen ze namens u zullen hosten en nog steeds het accountbeheer hebben verdeeld over de voorkeur van de klant?
  8. Interoperatie binnen apps of netwerken – Kan een dapp een andere dapp bellen? Kan een netwerk / zijketen verwijzen naar informatie van het gekoppelde netwerk?

Gebruikersbeheer / prestaties / privacy

  1. Prestaties van transactieverwerking – Hoe snel kunt u transacties in de wachtrij plaatsen, ze verwerken (in batches / blokken) en ervoor zorgen dat de wachtrij wordt leeggemaakt met de melding ‘opgeslagen’?
  2. Schaalbaarheid van transactieverwerking – Is het systeem modulair schaalbaar (horizontaal of verticaal) ontworpen om hogere verwerkingssnelheden te ondersteunen?
  3. Gelijktijdige veranderingen – Zijn er obstakels om hetzelfde contract of saldo meerdere keren bij te werken voordat het activum volledig is gewijzigd?
  4. Transactiedistributieprestaties – Wanneer wordt uw transactie bijgewerkt voor alle partijen? Is het wanneer het blok wordt verwerkt? Na 6 blokdieptes? Nadat de stroom is voltooid en ondertekend door alle partijen?
  5. Multi-threading – Kunnen uw transactieverwerking en consensus multi-threaded of verdeeld zijn over meerdere netwerkdeelnemers en toch overeenstemming bereiken over dezelfde gouden bron? Splits je verschillende soorten executies op?
  6. Privacy mechanismen voor verduistering van velden – Kunt u specifieke velden van het gegevensopslagmechanisme delen met alleen specifieke gebruikers? Kun je bedrijfslogica uitvoeren die veldwaarden vergelijkt zonder de informatie vrij te geven (bijvoorbeeld Aztec en ZKsnarks)?
  7. Privacymechanismen voor ontvangers (vertrouwelijkheid) – Kunt u openbare sleutels automatisch laten rouleren, zodat de eindgebruiker naar wie u de informatie verzendt, niet kan worden omgezet in een bekende identiteit??
  8. Privacymechanismen voor afzenders (transactieverkeerpatronen) – Kunt u de transactie niet met alle partijen delen in gevallen waarin u wilt dat alleen uw geïdentificeerde partijen de transactie zien??
Raadpleeg onze blockchain-experts

Ons wereldwijde Solutions-team biedt blockchain-training, strategisch advies, implementatiediensten en samenwerkingsmogelijkheden. Neem contact met ons op Nieuwsbrief Abonneer u op onze nieuwsbrief voor het laatste Ethereum-nieuws, bedrijfsoplossingen, bronnen voor ontwikkelaars en meer.Volledige gids voor Blockchain-bedrijfsnetwerkenGids

Volledige gids voor Blockchain-bedrijfsnetwerken

Inleiding tot tokenisatieWebinar

Inleiding tot tokenisatie

De toekomst van digitale activa en defiWebinar

De toekomst van financiën: digitale activa en deFi

Wat is Enterprise EthereumWebinar

Wat is Enterprise Ethereum?

Centrale banken en de toekomst van geldWit papier

Centrale banken en de toekomst van geld

Komgo Blockchain voor Commodity Trade FinanceCase Stud

Komgo: Blockchain voor Commodity Trade Finance

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me
Like this post? Please share to your friends:
Adblock
detector
map