30 Blockchain platformas tehniskie faktori

emuārs 1NewsDevelopersEnterpriseBlockchain ExplainedEvents and ConferencesPressBiļeteni

Abonējiet mūsu biļetenu.

Epasta adrese

Mēs cienām jūsu privātumu

SākumsBlogsUzņēmums Blockchain

30 Blockchain platformas tehniskie faktori

Galvenie tehniskie aspekti, kas jāņem vērā, izvēloties blokķēdes platformu sava biznesa lietošanai. Clemens Wan, 2020. gada 5. marts

2

Klemens Vans ir ConsenSys risinājumu arhitekts. Viņš raksta 30 seelemons.com sarakstus.

Ja jūsu izvēlētajai blokķēdes platformai ir mazāka saistība ar uzņēmējdarbības faktoriem (skat. 30 Blockchain platformas uzņēmējdarbības faktorus), iespējams, jūs aplūkojat dažus tehniskos aspektus savam lietošanas gadījumam. Šis 30 saraksts sastāv no blokķēdes specifiskiem jautājumiem, kas būtu jāņem vērā, pārbaudot platformu.

DevOps / Tīkls / Izvietošana / Protokols

  1. Blockchain slāņa izvietošanas elastība – Vai platformai ir publiska instance? Atļauts? Privāts? Hibrīds?
  2. Optimālais mezglu skaits – Cik mezglu ir nepieciešams tīkla atbalstam? Katram dalībniekam pa vienam? Vai es varu mijiedarboties ar tīklu, nedarbinot mezglu?
  3. Konteiners – Vai platformu var dokot un izvietot, izmantojot Kubernetes?
  4. Tīkla identitātes pārvaldības slānis – Kā tiek pārvaldītas mezglu un personu atļaujas? Vai super lietotājiem ir ierobežojumi? Vai ir visu tīkla dalībnieku avota tīkla karte (piemēram, DNS veida pakalpojums – ENS Ethereum)?
  5. Vienprātības mehānisms – Vai sistēmas pamatā ir darba pierādījums? Likmes pierādījums? Autoritātes pierādījums? Pierādījums par pagājušo laiku? To, iespējams, izlemj pārvaldības iestatījumi un entītijas, pamatojoties uz to, kas ir visefektīvākais jūsu lietošanas gadījumā.
  6. Ziņapmaiņa starp organizācijām – Vai privātiem ziņojumiem ir atsevišķi slāņi? Vai šī ir AMQP bāze? RabbitMQ? XMPP? Droša Scuttlebutt?
  7. Darījumu apstrādes metodika – Kāda darbību kārtība notiek darījumu apstrādes ziņā? Kad protokols pasūta, apstiprina un izpilda darījumus? Ethereum tīklā TX tiek nosūtīti apstiprināšanas mezgliem, kuri pasūta / apstiprina pirms “pareizā” bloka izpildes un izplatīšanas. Kordā TX tiek individuāli apstiprināta ar nepieciešamību zināt mezglus caur Flow Framework, līdz notārs to parakstīs un pārdalīs.
  8. Kriptogrāfija – Kādas bibliotēkas izmanto un atbalsta jaukšanas un paraksti? (piem., secp256k1 Ethereum)
  9. Kriptogrāfijas pievienojamība – Vai konkrēti mezgli var izvēlēties izmantot citu kriptogrāfijas bibliotēku, pamatojoties uz reģionālajiem drošības noteikumiem? (piemēram, NIST atbilstība)
  10. Failu koplietošanas paņēmieni – Katram digitālajam īpašumam jābūt kaut kā likumīgi noenkurotam caur organizāciju, kas tur tā glabāšanu, vai juridisko dokumentu / prozu, uz kuru ir atsauce kodā. Kā faili tiek koplietoti starp organizācijām ar platformu? Vai tie tiek saglabāti vienā platformā? Vai tie tiek dublēti līdzīgi?
  11. Juridiskā noenkurošana – Vai protokolā ir iestrādāta juridiska proza ​​vai juridisku dokumentu ieviešana (piemēram, OpenLaw)?
  12. Acīmredzami pret viltojumiem un izturīgi pret viltojumiem – Vai kāds var mainīt jūsu vietējā mezgla stāvokli un tā vēsturi? Ja kaut kādā veidā tiktu noņemts darījums vai stāvoklis, vai tas viss izraisītu sinhronizāciju? Vai atsauces vēsturiskos datus var modificēt vai dzēst un par kuriem var vienoties visas puses?
  13. Darījumu atgūšana – Kā mezgls atgūst darījumus? Ja jūsu darījumi netiek pilnībā izplatīti visām pusēm, kādi ir jaunākās saskaņotās versijas lejupielādes mehānismi?
  14. DAO iespējas – Vai ir dappu piemēri, kas abstrahē pārvaldības atbildību? Tas var būt noderīgi tīkla atkārtotai izmantošanai, lai uzturētu balsošanu un pārvaldību.

Izstrādātāja pieredze / Stack Applications top

  1. Pieteikšanās atbildība – Par ko jums jāuztraucas, veidojot kaudzes lietojumprogrammas augšdaļu (dapp)? Vai jums ir jāuzņem savs mezgls? Vai esat atbildīgs arī par dapp atbilstošo tīmekļa serveru un saskarņu izvietošanu? Kā lietotāji maksās par jūsu lietojumprogrammu?
  2. Dapp slāņa izvietošana – Pamatojoties uz atļaujām, kā viedie līgumi tiek izvietoti tīklā? Persona (piemēram, baltajā adresē iekļauta adrese)? Ar mezglu (piemēram, LEI identitāti)? Reģistrēta persona (piemēram, tīklam pievienots biznesa tīkls)? Infrastruktūras nodrošinātājs (piemēram, Kaleido Marketplace)? Vai izvietošanai ir nepieciešamas mezglu līmeņa atļaujas?
  3. Viedās līgumu valodas – Kādā valodā tiek rakstīts viedais līgums? Vai tas ir pārbaudīts? Vai tai ir laba kopiena?
  4. Viedo līgumu bibliotēkas un standarti – Vai ir saskaņotas drošas bibliotēkas / funkcijas (piemēram, OpenZeppelin), kuras tiek uzturētas un revidētas? Vai ir plaši vienojušās par standartiem atbilstošu funkciju ieviešanu (piemēram, ERC-20, ERC-721 utt.)?
  5. Gudra līguma jaunināšana – Kā tiek atjauninātas lietojumprogrammas? Vai ir labi definēti viedā līguma koda jaunināšanas modeļi?
  6. Piekļuve atsauces un tirgus datiem – Tīkla ietvaros pieejamos orākulus var izsaukt, lai saņemtu nepieciešamo informāciju, lai veiktu iedarbinātu darbību?
  7. Ieteicamā personu identitātes pārvaldība – Vai publisko / privāto atslēgu pāri un adreses dabiski pieprasa, lai indivīdi paturētu paši savas atslēgas? Vai arī tas ir reāli pieņemams, ka starpnieki tos mitinās jūsu vārdā un viņiem joprojām būs konta pārvaldība, kas sadalīta pa klientu vēlmēm?
  8. Sadarbojieties lietotnēs vai tīklos – Vai dapp var saukt citu dapp? Vai tīkla / sānu ķēdes atsauces informāciju var iegūt no piesaistītā tīkla?

Lietotāju kontrole / veiktspēja / privātums

  1. Darījumu apstrādes veiktspēja – Cik ātri jūs varat sarindot darījumus, tos apstrādāt (partijās / blokos) un pārliecināties, ka rinda ir notīrīta, paziņojot par “saglabātajiem”?
  2. Darījumu apstrādes mērogojamība – Vai sistēma ir veidota ar modulāri pielāgojamu (horizontāli vai vertikāli), lai atbalstītu augstākus apstrādes ātrumus?
  3. Vienlaicīgas izmaiņas – Vai pastāv šķēršļi viena un tā paša līguma vai bilances atjaunināšanai vairākas reizes, pirms aktīvs tiek pilnībā mainīts?
  4. Darījumu izplatīšanas veiktspēja – Kad jūsu darījums tiek atjaunināts visām pusēm? Vai tas ir tad, kad bloks tiek apstrādāts? Pēc 6 bloku dziļumiem? Pēc tam, kad plūsma ir pabeigta un to parakstījušas visas puses?
  5. Vairāku vītņu vītne – Vai jūsu darījumu apstrāde un vienprātība var būt vairāku pavedienu vai sadalīta vairākos tīkla dalībniekos un joprojām vienoties par vienu un to pašu zelta avotu? Vai jūs sadalāt dažāda veida nāvessoda izpildi??
  6. Privātuma mehānismi lauka aizsegšanai – Vai varat koplietot noteiktus datu glabāšanas mehānisma laukus tikai ar konkrētiem lietotājiem? Vai varat palaist biznesa loģiku, kas salīdzina lauka vērtības, neatklājot informāciju (piemēram, Aztec un ZKsnarks)?
  7. Uztvērēju privātuma mehānismi (konfidencialitāte) – Vai jūs varat automātiski pagriezt publiskās atslēgas tā, lai gala lietotājam, kuram sūtāt informāciju, nebūtu iespējams noteikt zināmu identitāti?
  8. Sūtītāju konfidencialitātes mehānismi (darījumu trafika modeļi) – Vai jūs nevarat kopīgot darījumu ar visām pusēm gadījumos, kad vēlaties, lai darījumu redzētu tikai jūsu noteiktās puses?
Konsultējieties ar mūsu bloku ķēdes ekspertiem

Mūsu globālā risinājumu komanda piedāvā blokķēdes apmācību, stratēģiskas konsultācijas, ieviešanas pakalpojumus un partnerības iespējas. Sazinieties ar mums informatīvais izdevums Abonējiet mūsu biļetenu, lai iegūtu jaunākos Ethereum jaunumus, uzņēmuma risinājumus, izstrādātāju resursus un daudz ko citu. E-pasta adrese Ekskluzīvs satursPilnīgs Blockchain biznesa tīklu ceļvedisVadīt

Pilnīgs Blockchain biznesa tīklu ceļvedis

Ievads tokenizācijāTīmekļa seminārs

Ievads tokenizācijā

Finanšu digitālo aktīvu un DeFi nākotneTīmekļa seminārs

Finanšu nākotne: digitālie aktīvi un DeFi

Kas ir Enterprise EthereumTīmekļa seminārs

Kas ir Enterprise Ethereum?

Centrālās bankas un naudas nākotneBaltā grāmata

Centrālās bankas un naudas nākotne

Komgo Blockchain preču tirdzniecības finansēšanaiLietu izpēte

Komgo: Blockchain preču tirdzniecības finansēšanai

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me