30 Blockchain-plattforms tekniske faktorer

blogg 1NyheterUtviklereEnterpriseBlockchain ExplainedBegivenheter og konferanserPresseNyhetsbrev

Abonner på vårt nyhetsbrev.

Epostadresse

Vi respekterer personvernet ditt

HomeBlogEnterprise Blockchain

30 Blockchain-plattforms tekniske faktorer

Viktige tekniske aspekter du bør vurdere når du velger en blockchain-plattform for ditt forretningsbruk. Av Clemens Wan 5. mars 2020 Publisert 5. mars 2020

2

Clemens Wan er løsningsarkitekt hos ConsenSys. Han skriver lister over 30 seelemons.com.

Hvis ditt valg av blockchain-plattform har mindre å gjøre med forretningsfaktorene (se 30 Blockchain Platform Business Factors), ser du kanskje på noen av de tekniske aspektene for din brukstilfelle. Denne listen over 30 går gjennom blockchain-spesifikke spørsmål som du bør huske på når du vurderer en plattform.

DevOps / Network / Deployment / Protocol

  1. Blockchain-lagdistribusjonsfleksibilitet – Har plattformen en offentlig instans? Tillatt? Privat? Hybrid?
  2. Optimal antall noder – Hvor mange noder trengs for å støtte nettverket? En for hvert medlem? Kan jeg samhandle med nettverket uten å kjøre en node?
  3. Containerisering – Kan plattformen dockeriseres og distribueres via Kubernetes?
  4. Nettverksidentitetsstyringslag – Hvordan håndteres tillatelser for noder og enkeltpersoner? Er det begrensninger for superbrukere? Er det et kildenettverkskart over alle parter i nettverket (f.eks. DNS-lignende tjeneste – ENS i Ethereum)?
  5. Konsensusmekanisme – Er systemet basert på Proof of Work? Bevis for stav? Bevis for autoritet? Bevis på forløpt tid? Dette avgjøres sannsynligvis av styringsoppsettet og enhetene basert på hva som er mest effektivt for din brukstilfelle.
  6. Meldinger mellom organisasjoner – Finnes det separate lag for private meldinger? Er dette AMQP-basert? RabbitMQ? XMPP? Sikker Scuttlebutt?
  7. Metodikk for transaksjonsbehandling – Hvilken rekkefølge av aktiviteter skjer når det gjelder behandling av transaksjoner? Når bestiller, validerer og utfører protokollen transaksjonene? I Ethereum sendes TX-er til validerende noder som bestiller / validerer før de utfører og distribuerer den “riktige” blokken. I Corda blir TX-er validert individuelt av behovet for å kjenne noder gjennom Flow Framework til det blir signert og distribuert av notarius..
  8. Kryptografi – Hvilke biblioteker brukes og støttes av hasjene og signaturene? (f.eks. secp256k1 for Ethereum)
  9. Pluggbarhet av kryptografi – Kan spesifikke noder velge å bruke et annet kryptobibliotek basert på deres regionale sikkerhetsregler? (f.eks. NIST-samsvar)
  10. Fildelingsteknikker – Hvert digitalt aktivum må på en eller annen måte være lovlig forankret gjennom organisasjonen som har forvaring eller det juridiske dokumentet / prosaen som det er referert til i koden. Hvordan deles filer mellom organisasjoner med plattformen? Lagres de på samme plattform? Er de sikkerhetskopiert på samme måte?
  11. Juridisk forankring – Er det innebygd juridisk prosa eller juridisk dokumentimplementering (f.eks. OpenLaw) i protokollen?
  12. Slagsikker mot tukleresistent – Kan noen endre din lokale node-tilstand og dens historie? Hvis en transaksjon eller stat på en eller annen måte ble fjernet, ville det føre til at alt var ute av synkronisering? Kan de refererte historiske dataene endres eller slettes og avtales av alle parter?
  13. Transaksjonsgjenoppretting – Hvordan gjenoppretter en node transaksjonene? Hvis transaksjonene dine ikke distribueres fullt ut til alle parter, hva er mekanismene for å laste ned den siste avtalt versjonen?
  14. DAO-evne – Er det eksempler på dapps som abstraherer styringsansvaret? Dette kan være nyttig for å gjenbruke nettverket for å opprettholde stemmegivning og styring.

Utvikleropplevelse / toppen av Stack-applikasjoner

  1. Søknadsansvar – Når du bygger toppen av stack-applikasjonen (dapp), hva trenger du å bekymre deg for? Må du være vert for din egen node? Er du også ansvarlig for å distribuere dappens tilsvarende webservere og grensesnitt? Hvordan vil brukerne betale for søknaden din?
  2. Dapp lag distribusjon – Basert på tillatelser, hvordan distribueres smarte kontrakter i nettverket? Av en person (f.eks. Godkjent adresse)? Ved en node (f.eks. LEIs identitet)? Av en registrert enhet (f.eks. Virksomhetsnettverk lagt til nettverket)? Av infrastrukturleverandøren (f.eks. Kaleido Marketplace)? Trenger du tillatelser på nodenivå for å distribuere?
  3. Smarte kontraktsspråk – Hvilket språk er den smarte kontrakten skrevet på? Har den blitt testet? Har det et godt fellesskap?
  4. Smarte kontraktsbiblioteker og standarder – Er det avtalt sikre biblioteker / funksjoner (f.eks. OpenZeppelin) som vedlikeholdes og revideres? Er det vidt enige om implementeringer av funksjoner som er rullet opp til standarder (f.eks. ERC-20, ERC-721, osv.)?
  5. Smart kontraktsoppgraderbarhet – Hvordan oppdateres applikasjoner? Er det veldefinerte oppgraderingsmønstre for smart kontraktskoden?
  6. Tilgang til referanse- og markedsdata – Innen nettverket kan hvilke tilgjengelige orakler kalles for å motta den nødvendige informasjonen for å utføre en utløst handling?
  7. Anbefalt identitetshåndtering av enkeltpersoner – Insisterer de offentlige / private nøkkelparene og adressene naturlig på at enkeltpersoner opprettholder sine egne nøkler? Eller antar dette realistisk at mellommenn vil være vert for dem på dine vegne og fortsatt har kontoadministrasjon fordelt på klientpreferanser?
  8. Interop i apper eller nettverk – Kan en dapp ringe en annen dapp? Kan et nettverk / sidekjede referanseinformasjon fra det tethered nettverket?

Brukerkontroll / ytelse / personvern

  1. Transaksjonsbehandlingsytelse – Hvor raskt kan du køe opp transaksjoner, behandle dem (i grupper / blokker), og sørge for at køen blir ryddet med varsel om “lagret”?
  2. Skalerbarhet i transaksjonsbehandling – Er systemet designet med modulær skalerbar (horisontalt eller vertikalt) for å støtte høyere prosesseringshastigheter?
  3. Samtidige endringer – Er det veisperringer for å oppdatere den samme kontrakten eller balansere flere ganger før eiendelen endres fullstendig?
  4. Transaksjonsfordelingsytelse – Når oppdateres transaksjonen din til alle parter? Er det når blokken er behandlet? Etter 6 blokkdybder? Etter at strømmen er fullført og signert av alle parter?
  5. Multi-threading – Kan transaksjonsbehandlingen og konsensusen din være flertrådet eller splittet på tvers av flere nettverksdeltakere og fortsatt være enige om samme gyldne kilde? Deler du forskjellige typer henrettelser?
  6. Personvernmekanismer for feltmuskulasjon – Kan du dele spesifikke felt i datalagringsmekanismen med bare spesifikke brukere? Kan du kjøre forretningslogikk som sammenligner feltverdier uten å avsløre informasjonen (f.eks. Aztec og ZKsnarks)?
  7. Personvernmekanismer for mottakere (konfidensialitet) – Kan du rotere offentlige nøkler automatisk slik at sluttbrukeren du sender informasjonen til ikke kan løses til en kjent identitet?
  8. Personvernmekanismer for avsendere (transaksjonstrafikkmønstre) – Kan du ikke dele transaksjonen til alle parter i tilfeller der du bare vil at dine identifiserte parter skal se transaksjonen?
Ta kontakt med våre blockchain-eksperter

Vårt globale løsningsteam tilbyr blockchain-opplæring, strategisk rådgivning, implementeringstjenester og partnerskapsmuligheter. Kontakt oss Nyhetsbrev Abonner på vårt nyhetsbrev for de siste Ethereum-nyhetene, bedriftsløsninger, utviklerressurser med mer. E-postadresse Eksklusivt innholdKomplett guide til Blockchain Business NetworksGuide

Komplett guide til Blockchain Business Networks

Introduksjon til tokeniseringWebinar

Introduksjon til tokenisering

Fremtiden for digitale eiendeler og deFiWebinar

Fremtidens økonomi: digitale eiendeler og deFi

Hva er Enterprise EthereumWebinar

Hva er Enterprise Ethereum?

Sentralbanker og pengens fremtidHvitt papir

Sentralbanker og pengens fremtid

Komgo Blockchain for handelsvareøkonomiCase Stud

Komgo: Blockchain for handelsvareøkonomi

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