30 Blockchain-alustan tekniset tekijät

blogi 1NewsDevelopersEnterpriseBlockchain ExplainedTapahtumat ja konferenssitPainaUutiskirjeet

tilaa uutiskirjeemme.

Sähköpostiosoite

Kunnioitamme yksityisyyttäsi

EtusivuBlogiYritys Blockchain

30 Blockchain-alustan tekniset tekijät

Tärkeimmät tekniset näkökohdat, jotka on otettava huomioon, kun valitset blockchain-alustan yrityskäyttöön. – kirjoittanut Clemens WanMarraskuu 5, 2020 Lähetetty 5. maaliskuuta 2020

2

Clemens Wan on ConsenSysin ratkaisuarkkitehti. Hän kirjoittaa luettelot 30 seelemons.comista.

Jos valitsemallasi blockchain-alustalla ei ole mitään tekemistä liiketoimintatekijöiden kanssa (katso 30 Blockchain Platform -liiketoimintatekijää), ehkä etsit joitain käyttötapauksesi teknisiä näkökohtia. Tämä 30: n luettelo kulkee blockchain-kohtaisten kysymysten läpi, joiden tulisi olla mielessä, kun alusta tarkistetaan.

DevOps / verkko / käyttöönotto / protokolla

  1. Blockchain-kerroksen käyttöönoton joustavuus – Onko alustalla julkista instanssia? Onko sinulla lupa? Yksityinen? Hybridi?
  2. Optimaalinen solmujen määrä – Kuinka monta solmua tarvitaan verkon tukemiseen? Yksi jokaiselle jäsenelle? Voinko olla vuorovaikutuksessa verkon kanssa suorittamatta solmua?
  3. Kontti – Voidaanko alusta telakoida ja ottaa käyttöön Kubernetesin kautta?
  4. Verkkotunnuksen hallintataso – Kuinka solmujen ja yksilöiden käyttöoikeuksia hallitaan? Onko superkäyttäjille rajoituksia? Onko verkon kaikkien osapuolten lähdeverkkokartta (esim.DNS-tyyppinen palvelu – ENS Ethereumissa)?
  5. Konsensusmekanismi – Perustuuko järjestelmä työn todistamiseen? Todiste vaarnasta? Todiste viranomaisesta? Todiste kuluneesta ajasta? Tämän päättävät todennäköisesti hallintajärjestelmät ja entiteetit sen perusteella, mikä on tehokkainta käyttötapauksessasi.
  6. Viestintä organisaatioiden välillä – Onko yksityisviesteille erillisiä tasoja? Onko tämä AMQP-pohjainen? RabbitMQ? XMPP? Kiinnitä Scuttlebutt?
  7. Tapahtumien käsittelymenetelmät – Mikä toimintojen järjestys tapahtuu tapahtumien käsittelyssä? Milloin protokolla tilaa, vahvistaa ja suorittaa tapahtumat? Ethereumissa TX: t lähetetään validoiville solmuille, jotka tilaavat / validoivat ennen “oikean” lohkon suorittamista ja jakamista. Cordassa TX: t vahvistetaan erikseen tarpeen tuntea solmut Flow Frameworkin kautta, kunnes notaari allekirjoittaa ja jakaa sen uudelleen.
  8. Salaus – Mitä kirjastoja hash ja allekirjoitukset käyttävät ja tukevat? (esim. secp256k1 Ethereumille)
  9. Salauksen liitettävyys – Voivatko tietyt solmut päättää käyttää eri salauskirjastoa alueellisten turvallisuussääntöjensä perusteella? (esim. NIST-yhteensopivuus)
  10. Tiedostojen jakamistekniikat – Jokainen digitaalinen omaisuus on jotenkin laillisesti ankkuroitava sen säilytyksessä olevan organisaation tai koodissa mainitun oikeudellisen asiakirjan / proosan kautta. Kuinka tiedostot jaetaan organisaatioiden välillä alustan kanssa? Tallennetaanko he samalle alustalle? Varmistetaanko ne samalla tavalla?
  11. Laillinen ankkurointi – Onko protokollassa sisäänrakennettu oikeudellinen proosa tai laillisten asiakirjojen toteutus (esim. OpenLaw)?
  12. Peukalointi ilmeinen vs. peukalointi – Voiko joku muuttaa paikallisen solmun tilaa ja sen historiaa? Jos jokin tapahtuma tai tila poistettaisiin, aiheuttaisiko se kaiken synkronoinnin? Voivatko kaikki osapuolet muokata tai poistaa viitattuja historiallisia tietoja??
  13. Tapahtumien palautus – Kuinka solmu palauttaa tapahtumat? Jos tapahtumiasi ei jaeta kokonaan kaikille osapuolille, mitkä ovat uusimman sovitun version lataamisen mekanismit?
  14. DAO-ominaisuus – Onko olemassa esimerkkejä dappeista, jotka tiivistävät hallintovastuun? Tästä voi olla hyötyä verkon uudelleenkäytössä äänestyksen ja hallinnon ylläpitämiseksi.

Kehittäjien kokemus / pino-sovellusten alkuun

  1. Sovellusvastuu – Mistä sinun on huolehdittava, kun rakennat pino-sovelluksen yläosaa (dapp)? Pitääkö sinun isännöidä omaa solmua? Oletko vastuussa myös dappin vastaavien verkkopalvelimien ja käyttöliittymien käyttöönotosta? Kuinka käyttäjät maksavat sovelluksestasi?
  2. Dapp-kerroksen käyttöönotto – Kuinka älykkäät sopimukset otetaan käyttöön oikeuksien perusteella verkossa? Yksityishenkilö (esim. Sallittujen luettelossa oleva osoite)? Solmun (esim. LEI: n identiteetti) avulla? Rekisteröidyn yksikön (esim. Verkkoon lisätty yritysverkko)? Infrastruktuurin tarjoaja (esim. Kaleido Marketplace)? Tarvitsetko solmutason käyttöoikeudet käyttöönottoon?
  3. Älykkäät sopimuskielet – Millä kielellä älykäs sopimus on kirjoitettu? Onko se testattu? Onko sillä hyvä yhteisö?
  4. Älykkäät sopimuskirjastot ja standardit – Onko olemassa sovittuja turvallisia kirjastoja / toimintoja (esim. OpenZeppelin), joita ylläpidetään ja tarkastetaan? Onko standardien mukaan kootut toiminnot toteutettu laajalti (esim. ERC-20, ERC-721 jne.)?
  5. Älykäs sopimuksen päivitettävyys – Kuinka sovelluksia päivitetään? Onko älykästä sopimuskoodia varten tarkoin määriteltyjä päivitysmalleja?
  6. Pääsy viite- ja markkinatietoihin – Mitä käytettävissä olevia oraakeleita voidaan verkon sisällä kutsua vastaanottamaan tarvittavat tiedot laukaistun toiminnan suorittamiseksi?
  7. Suositeltu yksilöiden henkilöllisyyden hallinta – Vaativatko julkisen / yksityisen avaimen parit ja osoitteet luonnollisesti, että henkilöt säilyttävät omat avaimensa? Vai oletetaanko realistisesti, että välittäjät isännöivät heitä puolestasi ja että tilinhallinta on edelleen jaettu asiakkaan mieltymysten kesken?
  8. Pidä yhteyttä sovelluksissa tai verkoissa – Voiko dapp soittaa toiselle dappille? Voivatko verkko / sivuketjun viitetiedot kytketystä verkosta?

Käyttäjän hallinta / Suorituskyky / Yksityisyys

  1. Tapahtumien käsittelyn suorituskyky – Kuinka nopeasti voit jonottaa tapahtumia, käsitellä niitä (erissä / lohkoissa) ja varmistaa, että jono tyhjennetään ilmoittamalla “tallennetuista”?
  2. Tapahtumien käsittelyn skaalautuvuus – Onko järjestelmä suunniteltu modulaarisesti skaalattavaksi (vaaka- tai pystysuunnassa) tukemaan korkeampia käsittelynopeuksia??
  3. Samanaikaiset muutokset – Onko esteitä saman sopimuksen tai saldon päivittämiselle useita kertoja ennen kuin omaisuus on täysin muutettu??
  4. Tapahtumien jakamisen suorituskyky – Milloin tapahtumasi päivitetään kaikille osapuolille? Onko se silloin, kun lohko käsitellään? 6 lohkosyvyyden jälkeen? Kun virta on saatu päätökseen ja kaikki osapuolet ovat allekirjoittaneet sen?
  5. Monisäikeinen – Voivatko tapahtumien käsittely ja konsensus olla monisäikeisiä tai pilkkoa useiden verkon osallistujien kesken ja sopivatko silti samasta kultaisesta lähteestä? Jaatko erilaisia ​​teloituksia?
  6. Tietosuojamekanismit kenttähämpöä varten – Voitteko jakaa tietotallennusmekanismin tietyt kentät vain tiettyjen käyttäjien kanssa? Voitteko käyttää liiketoimintalogiikkaa, joka vertaa kentän arvoja paljastamatta tietoja (esim. Aztec ja ZKsnarks)?
  7. Vastaanottimien tietosuojamekanismit (luottamuksellisuus) – Voitko kiertää julkisia avaimia automaattisesti siten, että loppukäyttäjä, jolle lähetät tietoja, ei ole tunnistettavissa tunnetulle henkilöllisyydelle?
  8. Lähettäjien tietosuojamekanismit (tapahtumaliikennemallit) – Etkö voi jakaa tapahtumaa kaikille osapuolille, jos haluat, että vain tunnistamasi osapuolet näkevät tapahtuman?
Ota yhteyttä blockchain-asiantuntijoihimme

Globaali ratkaisutiimimme tarjoaa blockchain-koulutusta, strategista neuvontaa, toteutuspalveluja ja kumppanuusmahdollisuuksia. Ota yhteyttä uutiskirjeeseenTilaa uutiskirjeemme, niin saat uusimmat Ethereum-uutiset, yritysratkaisut, kehittäjien resurssit ja paljon muuta.Täydellinen opas Blockchain-yritysverkoihinOpas

Täydellinen opas Blockchain-yritysverkoihin

Johdatus tokenisaatioonWebseminaari

Johdatus tokenisaatioon

Digitaalisten varojen ja DeFi: n tulevaisuusWebseminaari

Rahoituksen tulevaisuus: digitaaliset varat ja DeFi

Mikä on Enterprise EthereumWebseminaari

Mikä on Enterprise Ethereum?

Keskuspankit ja rahan tulevaisuusValkoinen paperi

Keskuspankit ja rahan tulevaisuus

Komgo Blockchain hyödykekaupan rahoitukseenTapaustutkimus

Komgo: Blockchain for 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