ブロックチェヌン䞊に電子投祚システムを䜜成する方法は

前の蚘事で、ブロックチェヌン技術を䜿甚しお構築されたデヌタ亀換システムに぀いお説明したした。 成功した経隓から、このテクノロゞヌを䜿甚しお投祚システムずいう別の補品を䜜成するこずになりたした。 この蚘事では、システムの実装の詳现に぀いお説明したす。



投祚システムのブロックチェヌンずは䜕ですか



投祚は、瀟䌚にずっお重芁な問題に関する意思決定プロセスずしお、数千幎にわたっお人類に知られおいたす。 特別なアンフォラに色の぀いたボヌルを投げたり、手でゞェスチャヌしたりしお、暩限のある人の狭いサヌクルによっお決定が䞋された時代がありたした。 しかし、人口は増加し、瀟䌚は発展し、たすたす倚くの人々が意思決定プロセスに参加し始めたした-数十䞇、さらには数癟䞇人。 次に、投祚をカりントするこのような単玔な方法は、より耇雑な方法に眮き換えられたした。投祚所が䜜成され始め、アンフォラが投祚箱に、ボヌルが投祚に眮き換えられたした。 投祚ぞのこのアプロヌチは、人口の巚倧な倧衆の意芋を考慮するこずを可胜にしたしたが、いく぀かの欠点がありたす







説明されおいる問題の䞀郚は、電子投祚システムむンド、ブラゞル、゚ストニア、オランダ、米囜、ドむツなどで䜿甚されおいたすによっお解決されたすが、その䜿甚にはいく぀かの欠点もありたす。



  1. セキュリティの問題電子システムがハッキングされる可胜性があり、倚くの堎合スキャンダルがこれに関連付けられたす
  2. 遞挙結果の怜蚌に関する問題数えるこずができる玙の投祚ずは察照的に
  3. ゜フトりェア゚ラヌによるシステムの誀動䜜の可胜性


この点で、電子投祚装眮および電子投祚自䜓は䞖界的な慣行になっおいない。 さらに、電子投祚が圓初普及しおいた倚くの囜オランダ、むギリス、ドむツでは、技術の䞍完党性により最終的に䜿甚が制限され、より信頌性の高いアナログ投祚方法に戻りたした。



しかし、技術ず瀟䌚の発展により、人類はより安䟡で信頌性の高い投祚方法を探すようになっおいたす。 投祚にブロックチェヌン技術を䜿甚するず、既存の遞挙制床の問題のほずんどを解決できたす。



ブロックチェヌン技術は、トランザクションモデルに基づいおいたす。各ナヌザヌは、固有の公開キヌず秘密キヌを持぀りォレットを持ち、それを䜿甚しおデヌタの倉曎を確認したす。 すべおのトランザクション情報は連続しお曞き蟌たれたブロックに保存されるため、前のブロックのデヌタハッシュは次のブロックのデヌタに含たれたす。 これにより、デヌタの䞍倉性が保蚌されたす。ブロックを倉曎するず、埌続のすべおのブロックが自動的に無効になりたす。 ブロックチェヌンは、すべおのノヌドのすべおのトランザクションに関するすべおの情報を同時に完党に保存し、倉曎たたは削陀するこずはできたせん。 ブロックチェヌンは、特定のデゞタルオブゞェクトぞの財産暩の移動に関するデヌタを登録する分野で最も広く䜿甚されおいたす。最新の暗号通貚はすべおこの考えに基づいおいたす。 通垞「コむン」たたは「トヌクン」ず呌ばれるこのようなオブゞェクトは、システムの操䜜䞭に所定のアルゎリズムに埓っお自動的に䜜成「鉱山」するか、そうする暩限を持぀システムの参加者によっお発行されたす。



投祚システムでブロックチェヌンを䜿甚するずいう考え方は、ブロックチェヌンを䜿甚するず、物理オブゞェクト目的の色のボヌル、玙の投祚甚玙などで衚される誰かの声をデゞタルトヌクンに転送するこずで、叀代の投祚技術を眮き換えるこずができたす。 同時に、ビゞネスプロセスが物理的な䞖界からデゞタルに移行する他の倚くの堎合ず同様に、トランザクションコストが倧幅に削枛され、システムの可甚性が向䞊したす。 さらに、ブロックチェヌンを䜿甚するず、远加の利点が埗られたす。



  1. 結果の信頌性。 ブロックチェヌン技術を䜿甚しお線成された投祚の結果は停造できたせん。 投祚の開始時に発行された投祚数、りォレット間での投祚方法、取匕が行われた時間をい぀でも確認できたす。
  2. プロセスの透明性。 ブロックチェヌンを䜿甚するず、投祚プロセスを制埡できたす。関心のある人はすべおのデヌタの完党なコピヌを䜿甚しおノヌドを展開し、ブロックチェヌンレベルで独立しお分析できるためです。
  3. 匿名。 各投祚者は、ロヌカルマシン䞊で公開鍵ず秘密鍵のペアを䜜成する機䌚があり、特定のりォレットが自分に属しおいるこずを圌以倖の誰も知りたせん。 したがっお、参加者自身がこのりォレットが自分に属しおいるこずを発衚しない限り、このメンバヌがどのように投祚したかを誰も知るこずができたせん。
  4. デヌタ凊理速床。 異なる囜にオフィスを持぀郜垂、地域、囜、たたは䌁業内での投祚は、投祚ずデヌタ凊理の䞡方に倚倧なコスト、組織䞊の困難、および時間の損倱を䌎う可胜性がありたす。 地方分暩化により、各地域/åž‚/地区が独自のシステムノヌドを操䜜しお負荷を分散できるにもかかわらず、党囜の投祚結果を芋るこずができたす。


私たちの前に、ブロックチェヌンに投祚システムを実装する詊みがありたしたが、それらは広く配垃されたせんでした。 私たちの意芋では、これにはいく぀かの理由がありたす。



  1. 既存のプロゞェクトの倚くは、むヌサリアムやビットコむンなどの開発されたプラットフォヌムに基づいおいたす。 暗号通貚のレヌトは最近非垞に䞍安定になっおいたすが、同じEtherが幎の初めに比べお印象的に成長しおいるため、このプラットフォヌムに基づく投祚は非垞に高䟡になりたす。
  2. これらのシステムのほずんどは、Proof of Workアルゎリズムを䜿甚しおいるため、倧芏暡な投祚の結果の蚈算が非垞に遅くなりたす䞊蚘の問題に぀いおは、以䞋で詳しく説明したす 。

  3. これらは、独立した投祚プラットフォヌムずしお独占的に宣䌝されたす぀たり、投祚たたは参加するには、プラットフォヌムで明瀺的な登録プロセスを実行する必芁がありたす。
  4. それらのほずんどは、アむデアレベルのたたであるか、開発を停止したした


投祚プロセスに぀いお



システムでの投祚はトランザクションです。 投祚できる各オプションには独自のりォレットがあり、投祚者それぞれにりォレットもあるが投祚トヌクンを転送したす。 投祚ごずに䞀意のトヌクンが発行されるため、たずえば、お気に入りのお茶に投祚するために発行されるトヌクンは、遊び堎ではなく駐車堎の建蚭に投祚するこずはできたせん。



アプリケヌションの最終バヌゞョンでは、さたざたな皮類の投祚を実装したす。倚数決単玔倚数決によっお決定されたす、代替案提案されたものからいく぀かのオプションが遞択されたす、評䟡各オプションには、奜みに応じお特定の「重み」が割り圓おられたす。 それらはすべおオヌプン誰でも接続可胜およびクロヌズ参加するには招埅が必芁できたす。 そのような投祚が圹立぀可胜性のある分野は非垞に異なっおいる可胜性がありたすHOAの長の遞出、任意の競争での投祚、株匏䌚瀟の枠組み内での決定の投祚など。



プロトタむプ段階で、オヌプンスキヌムに埓っお投祚の倚数決シナリオに限定するこずにしたした。 これは、プラットフォヌムの機胜を実蚌するずずもに、このトピックが公共およびビゞネスにずっおどのように興味深いかを理解するために行われたした。



プロトタむプでは、投祚を䜜成するプロセスはいく぀かの段階で構成されおいたす。



  1. ナヌザヌはシステムにログむンし、ロヌカルマシンでキヌりォレットのペアを生成したす。 システムはナヌザヌにコヌドワヌドを芁求し、それを䜿甚しおりォレットデヌタを暗号化したす。その埌、暗号化されたりォレットを同じブロックチェヌンに保存しお、ナヌザヌを特殊なりォレット゜フトりェアをむンストヌルする必芁をなくしたす。 同時に、オヌプンフォヌムのりォレットはクラむアント偎でのみ凊理されたす。これにより、所有者のみがりォレットにアクセスできるようになりたす。 ただし、コヌドワヌドを玛倱するず、ナヌザヌはりォレットにもアクセスできなくなり、その堎合、圌を支揎するこずは䞍可胜になるこずを理解するこずが重芁です。
  2. プロトタむプ段階で、すべおの登録ナヌザヌに、システムでの投祚の䜜成に察しお支払うように蚭蚈された10個のIDVトヌクンを提䟛するこずにしたした。 圌らの助けを借りお、登録した参加者は投祚を敎理し、プロセス党䜓がどのように機胜するかを芋るこずができたす。 したがっお、りォレットを䜜成した盎埌に、凊理サヌバヌは10個のIDVをナヌザヌのりォレットにクレゞットしたす。
  3. システムで投祚を䜜成するコストは1IDVです。 したがっお、ナヌザヌが投祚を䜜成するず、システムは残高をチェックし、十分なお金がある堎合はトヌクンを1぀曞き萜ずし、投祚を準備したす。投祚オプション甚のりォレットを䜜成し、いく぀かの䞀意の投祚トヌクンを発行したす。 投祚の䜜成の結果䜜成に成功したかどうか、そうでない堎合はその理由は、特別なログに蚘録され、これもブロックチェヌンに保存されたす。


ナヌザヌが投祚したい堎合、以䞋が発生したす。



  1. 圌は䞀般リストから必芁な投祚を遞択し、それに参加する蚱可を芁求したす。
  2. システムは、ナヌザヌが投祚に参加できるかどうかを確認し、参加できる堎合は、この投祚の䞀意のトヌクンをナヌザヌに請求したす。
  3. ナヌザヌは提案されたオプションの1぀に投祚したす。その埌、システムはナヌザヌが投祚できるかどうかを確認し、投祚できる堎合は投祚トヌクンがりォレットから遞択した投祚オプションのりォレットに転送されたす。


投祚結果の確認は、いく぀かの方法で可胜です。 たず、各参加者のプロファむルには、「マむトランザクション」ずいうオプションがあり、りォレットの䜜成から始めお、すべおのトランザクションを確認できたす。 次に、投祚リストで特定の投祚の画面に移動し、投祚の詳现で遞択したオプションのりォレットからりォレットぞのトランザクションを芋぀けるこずができたす。 第䞉に、読み取り専甚ノヌドを展開し、結果のアカりンティングずブロックチェヌンレベルでのシステムの動䜜を確認する機䌚が垞にありたす。



遞択したテクノロゞヌに぀いお少し



プロゞェクトの技術コンポヌネントに぀いお説明する前に、次の点に泚意しおください。プロゞェクトの䞻なタスクは、サヌドパヌティアプリケヌションのブロックチェヌンプラットフォヌムに信頌できる祚を埋め蟌むための䟿利な手段を提䟛するこずです。 そのため、䟿利なAPIの開発に特別な泚意を払っおいたす。 もちろん、投祚のために顧客を提䟛したすが、䞻に投祚プラットフォヌムの機胜を実蚌するために顧客を開発しおいたす。 以䞋では、プロゞェクトの技術面に぀いお怜蚎したす。

以前のプロゞェクトず同様に、Mulitchainブロックチェヌンを基盀ずしお䜿甚したした。 次の考慮事項から進めたした。



  1. セキュリティ。 ほずんどのブロックチェヌンシステムの脆匱性の1぀は、匿名性ずいう独自の利点にありたす。 誰でも任意の数の曞き蟌みノヌドを拡匵できる堎合、倉曎された情報を含むノヌドの合蚈数の51を拡匵し、残りのノヌドが曞き蟌みのためにそれを受け入れるずいうリスクがありたす。これは、ブロックの最長チェヌンが続くためです。 これは51攻撃ず呌ばれたす。 このような攻撃を防ぐために、ほずんどの公開アルゎリズムは、Proof of Work確認アルゎリズムを䜿甚したす。各ノヌドは、特定の報酬「鉱山コむン」を受け取る耇雑な数孊的問題を解決したす。 問題の解決には、時間ずかなりの蚈算胜力が必芁です。 これにより、この皮の攻撃は非垞に費甚がかかり、実甚的ではありたせん。 マルチチェヌンの䞻な機胜は、コン゜ヌシアムの原則に埓っおブロックチェヌンを敎理するために特別に䜜成されおいるこずです。 お互いを知っおいる人々の限られた茪、すなわち 匿名ではありたせん。 実装では、ブロックチェヌンに接続するすべおのノヌドはデフォルトで読み取り専甚ノヌドです。 ぀たり、すべおのデヌタを保存したすが、新しいデヌタを曞き蟌む暩利はありたせん。 曞き蟌み蚱可を取埗するには、ノヌドはマスタヌノヌドから察応する暩利を取埗する必芁がありたす。 したがっお、認蚌されたノヌドによっおのみ新しいデヌタがシステムに曞き蟌たれるようにし、䞍正のリスクを枛らしたす。 同時に、読み取り専甚ノヌドはすべおのブロックチェヌンデヌタの完党なコピヌを受信し、䞀貫性のために投祚デヌタを個別に分析できたす。
  2. リ゜ヌスの匷床。 前述したように、䜜業の蚌明アルゎリズムを適甚する堎合、蚈算量が倚く、ナヌザヌ数が増加するず、䞀時的なリ゜ヌスも必芁になりたす。 この問題を解決するために、Proof of Authorityを優先しおProof of Workアルゎリズムを攟棄したす。この堎合、自身を識別したノヌドにのみ情報を蚘録する暩利を䞎えたす。 したがっお、新しい情報はより迅速にブロックチェヌンに分類され、「蚘録䟡栌」は最小限になりたす。
  3. 経隓。 過去のプロゞェクトでこのブロックチェヌンプラットフォヌムを䜿甚した経隓があり、発生する問題を解決する方法を熟知しおいたす。


技術郚分をさらに詳しく芋おみたしょう。 投祚構造は次のずおりです。



システムの構造は、3぀のセグメントに分けられたす。



UI-パブリックREST API共通領域セグメントに接続するか、匟頭の読み取りノヌド図には瀺されおいたせんに盎接接続する゚ンドナヌザヌアプリケヌション。 プロトタむプでは、機胜を実蚌するために、UI WebサむトをAngularのSPAずしお実装したした。 誰でも、REST APIたたは読み取り専甚マルチチェヌンノヌドをデヌタ゜ヌスずしお䜿甚しお、利甚可胜な任意のテクノロゞヌにUIを実装できたす。



共通領域 -これらは、マルチチェヌンが蚘録モヌドでデプロむされるシステムのNノヌドず、共有アクセス甚のAPIを備えたWebサヌバヌです。



ASP.NET Core 1.1で蚘述されたREST API Webサむト。 投祚メタデヌタ、メタデヌタアヌカむブ、投祚プロセス自䜓オプションを遞択しお投祚する、およびナヌザヌのりォレットを䜿甚しお䜜業を実装したした。 APIの詳现な説明はこちらにありたす 。



プラむベヌト゚リア -䞀般的なアクセス蚘録のために閉じられおいるシステムの䞀郚。凊理サヌバヌずナヌザヌ認蚌サヌバヌが含たれたす。

独自の郚分では、凊理サヌバヌずナヌザヌ認蚌サヌバヌを取り出したした。



凊理サヌバヌ



APS.NET Core 1.1のCommon REST APIず同様に実装されおいたす。 プロトタむプでは次のこずを担圓したす。



凊理サヌバヌによっお実行されるすべおのアクションは、マルチチェヌンに蚘録されたす。 したがっお、すべおのノヌドリヌダヌを含むはこれらのアクションを芋るこずができたす。



アむデンティティサヌバヌ



システムナヌザヌ認蚌サヌバヌ。 IdentityServer 4コンポヌネントを䜿甚しおASP.NET Core 1.1に実装されおいたす。



機胜





ナヌザヌプロファむルも暗号化された圢匏でマルチチェヌンに保存されたす。



プロトタむプの制限



私たちのシステムは、さたざたな皮類の投祚を実斜するように蚭蚈されおいたす。 ただし、プロトタむプの機胜を実蚌するために、参加者のオヌプンリストを䜿甚した単玔な倚数決のシナリオに限定するこずにしたした。 誰でもそのような投祚に参加できたす。 したがっお、この蚘事では、私的な投祚、評䟡、および代替投祚に参加するように人々を招埅するシナリオは考慮したせん。 たた、プロトタむプでは、厳密な識別メカニズムを実装しおいたせん。 これは意図的に行われたため、誰でも自分で詊すこずができたす。



詊䜜機



ここでプロトタむプを芋お投祚の䜜成を詊すこずができたす 。 読み取り専甚ノヌドを展開する堎合-サむトのフォヌムからご連絡ください-これを行う方法に぀いおの指瀺をお送りしたす。



All Articles