Cosmos: شبكة من دفاتر الأستاذ الموزعة
소개
오픈소스 생태계의 결합된 성공은 분산형 yle 공유 및 공개 암호화폐는 분산화된 인터넷 프로토콜에 대한 이해를 고취시켰습니다. 사회 경제적 인프라를 근본적으로 개선하는 데 사용될 수 있습니다. 우리는 Bitcoin 1와 같은 전문화된 blockchain 애플리케이션을 보았습니다. 암호화폐), Zerocash 2 및 Ethereum [3]와 같은 일반화된 smart contract 플랫폼 Etherium Virtual을 위한 수많은 분산 애플리케이션 Augur(예측 시장) 및 TheDAO과 같은 기계(EVM) [4] (투자 클럽). 그러나 현재까지 이 blockchain은 여러 가지 문제로 어려움을 겪었습니다. 총 에너지 비효율성, 열악함 또는 열악함을 포함한 단점 제한된 성능, 미성숙한 거버넌스 메커니즘. Bitcoin의 거래 처리량을 확장하기 위한 제안: 분리된 증인 [5] 및 BitcoinNG [6]은 수직 확장입니다. 단일 물리적 서버의 용량에 의해 제한되는 솔루션 완전한 감사 가능성의 속성을 보장하기 위해 기계. 라이트닝 네트워크 [7]은 Bitcoin 거래를 확장하는 데 도움이 될 수 있습니다.
일부 거래를 원장에서 완전히 제외하여 거래량 소액결제 및 개인정보 보호에 적합합니다. 지불 레일이지만 더 일반화된 경우에는 적합하지 않을 수 있습니다. 스케일링이 필요합니다. 이상적인 솔루션은 여러 개의 병렬 blockchain을 허용하는 솔루션입니다. 보안 속성을 유지하면서 상호 운용됩니다. 이것은 proof-of-work를 사용하면 불가능하지는 않지만 어려운 것으로 입증되었습니다. 병합됨 예를 들어 채굴을 통해 부모를 확보하는 작업이 가능해집니다. 체인은 하위 체인에서 재사용되지만 트랜잭션은 여전히 유지되어야 합니다. 각 노드별로 순서대로 검증되고 병합 채굴된 blockchain hashing 전력의 대부분이 공격에 취약합니다. 부모가 자식을 적극적으로 병합 채굴하지 않습니다. 학문적 검토 의 대체 blockchain 네트워크 아키텍처가 제공됩니다. 추가적인 맥락을 제공하고 다른 제안에 대한 요약을 제공합니다. 관련 작업의 단점. 여기에서는 새로운 blockchain 네트워크 아키텍처인 Cosmos을 제시합니다. 이 모든 문제를 해결하는 것입니다. Cosmos은 많은 사람들의 네트워크입니다 영역이라고 불리는 독립적인 blockchains. 영역은 다음에 의해 구동됩니다. 고성능을 제공하는 Tendermint Core [8], 일관되고 안전한 PBFT과 유사한 합의 엔진으로, 엄격한 포크책임이 악의적인 행위에 대한 통제를 보장합니다. 배우. Tendermint Core의 BFT 합의 알고리즘이 매우 적합합니다. 공개 proof-of-stake blockchain 확장용. Cosmos의 첫 번째 영역을 Cosmos 허브라고 합니다. Cosmos 허브는 간단한 다중 자산 proof-of-stake 암호화폐입니다. 네트워크가 적응하고 업그레이드. 또한 Cosmos 허브는 다음을 통해 확장할 수 있습니다. 다른 구역을 연결합니다. Cosmos 네트워크의 허브와 영역은 다음과 통신합니다. blockchain 간 통신(IBC) 프로토콜을 통해 서로 blockchains에 대한 일종의 가상 UDP 또는 TCP입니다. 토큰은 다음과 같습니다. 한 구역에서 다른 구역으로 안전하고 신속하게 이전됩니다.구역 간 유동성 교환이 필요하지 않습니다. 대신, 모든 영역 간 token 전송은 Cosmos 허브를 통과합니다. 각 구역이 보유한 token의 총량을 추적합니다. 는 허브는 각 영역을 다른 영역의 장애로부터 격리합니다. 왜냐하면 누구나 Cosmos 허브에 새 영역을 연결할 수 있습니다. 새로운 blockchain 혁신과의 미래 호환성을 위해. 이 섹션에서는 Tendermint 합의 프로토콜을 설명합니다. 그리고 이를 사용하여 애플리케이션을 구축하는 데 사용되는 인터페이스입니다. 더 알아보기 자세한 내용은 부록을 참조하세요. 전통적인 비잔틴 내결함성(BFT) 알고리즘에서 각 노드는 같은 무게를 가지고 있습니다. Tendermint에서 노드는 음수가 아닌 값을 갖습니다. 투표권의 양, 긍정적인 투표를 한 노드 전원을 validators라고 합니다. 검증인은 암호화 서명을 브로드캐스트하여 합의 프로토콜, 또는 다음 블록에 동의하기 위해 투표합니다. 검증인의 투표권은 처음부터 결정되거나 blockchain에 의해 결정적으로 변경되었습니다. 신청. 예를 들어, 다음과 같은 proof-of-stake 애플리케이션에서 Cosmos 허브에서 투표권은 다음에 의해 결정될 수 있습니다. 담보로 보세된 staking token 금액. 참고: ⅔ 및 ⅓과 같은 분수는 전체 투표의 분수를 나타냅니다. 모든 validator이 아닌 한 validator의 총 개수는 절대 아닙니다. 동일한 무게를 가지고 있습니다. >⅔는 “⅔ 이상”을 의미하고, ≥⅓은 “최소”를 의미합니다. ⅓”. Tendermint는 부분적으로 동기식인 BFT 합의 프로토콜입니다. DLS 합의 알고리즘 [20]에서 파생되었습니다. 텐더민트는
단순성, 성능 및 포크 책임으로 유명합니다. 프로토콜에는 알려진 validator 세트가 필요합니다. validator은 공개 키로 식별됩니다. 검증인은 다음을 시도합니다. 한 번에 하나의 블록에 대한 합의에 도달합니다. 여기서 블록은 목록입니다. 거래의. 블록에 대한 합의에 대한 투표는 다음과 같이 진행됩니다. 라운드. 각 라운드에는 라운드 리더 또는 제안자가 있습니다. 블록을 제안합니다. 그런 다음 validator은 단계적으로 다음 사항에 대해 투표합니다. 제안된 블록을 수락하거나 다음 라운드로 넘어갑니다. 는 라운드 제안자는 순서대로 결정적으로 선택됩니다. 투표권에 비례하여 validator 목록입니다. 프로토콜의 전체 세부 사항은 여기에 설명되어 있습니다. Tendermint의 보안은 최적의 비잔틴 사용에서 비롯됩니다. 절대다수(>⅔) 투표 및 잠금을 통한 내결함성 메커니즘. 이들은 함께 다음을 보장합니다. ≥⅓ 투표권은 다음 사항을 위반하는 비잔틴 방식이어야 합니다. 두 개 이상의 값이 커밋되는 안전. validator 세트가 안전 위반에 성공하거나 심지어 그렇게 하려는 시도는 프로토콜에 의해 식별될 수 있습니다. 이 혼란스러운 블록에 대한 투표와 방송이 모두 포함됩니다. 부당한 투표. 강력한 보장에도 불구하고 Tendermint는 탁월한 서비스를 제공합니다. 성능. 7개에 분산된 64개 노드의 벤치마크에서 5개 대륙의 데이터 센터, 상용 클라우드 인스턴스, Tendermint 합의는 한 번에 수천 건의 거래를 처리할 수 있습니다. 둘째, 커밋 대기 시간이 1~2초 정도입니다. 특히 1000건이 넘는 트랜잭션의 성능이 눈에 띕니다. 두 번째는 가혹한 적대적인 상황에서도 유지됩니다. validators가 악의적으로 제작된 투표를 충돌시키거나 방송합니다. 참조 자세한 내용은 아래 그림을 참조하세요.
Tendermint 합의 알고리즘의 주요 이점은 다음과 같습니다. 가벼운 클라이언트 보안으로 인해 모바일 및 사물 인터넷 사용 사례. Bitcoin 라이트 클라이언트는 동기화해야 합니다. 블록 헤더 체인을 찾아 가장 증거가 많은 것을 찾습니다. 작업, Tendermint 라이트 클라이언트는 변경 사항을 따라잡기만 하면 됩니다. validator 세트에 추가한 다음 >⅔ PreCommits를 확인하세요. 최신 상태를 결정하는 최신 블록입니다. 간결한 가벼운 클라이언트 증명으로 inter-blockchain도 가능합니다. 의사소통. Tendermint는 특정 행위를 방지하기 위한 보호 조치를 가지고 있습니다. 장거리 위험이 없는 이중 지출과 같은 주목할만한 공격 그리고 검열. 이에 대해서는 부록에서 더 자세히 설명합니다.Tendermint 합의 알고리즘은 다음과 같이 구현됩니다. Tendermint Core라는 프로그램입니다. 텐더민트 코어는 애플리케이션에 구애받지 않고 모든 것을 바꿀 수 있는 "합의 엔진" 결정론적 블랙박스 애플리케이션을 분산 복제로 변환 blockchain. Tendermint Core는 blockchain 애플리케이션에 연결됩니다. 애플리케이션 블록체인 인터페이스(ABCI) [17]를 통해. 따라서 ABCI blockchain 애플리케이션을 어떤 방식으로든 프로그래밍할 수 있습니다. 언어는 단순히 합의가 이루어지는 프로그래밍 언어가 아닙니다. 엔진이 작성되어 있습니다. 또한 ABCI를 사용하면 쉽게 기존 blockchain 스택의 합의 계층을 교체합니다. 우리는 잘 알려진 암호화폐인 Bitcoin에 비유합니다. Bitcoin는 각 노드가 유지 관리하는 암호화폐 blockchain입니다. 완전히 감사된 미사용 트랜잭션 출력(UTXO) 데이터베이스. 만약에 하나는 ABCI 위에 Bitcoin과 유사한 시스템을 만들고 싶었습니다. Tendermint Core는 다음을 담당합니다. 노드 간 블록 및 트랜잭션 공유 정식/불변의 거래 순서 확립( blockchain) 그 사이에 ABCI 애플리케이션은 다음을 담당합니다. UTXO 데이터베이스 유지 관리 거래의 암호화 서명 검증 거래가 존재하지 않는 자금을 지출하는 것을 방지 클라이언트가 UTXO 데이터베이스를 쿼리하도록 허용 Tendermint는 blockchain 디자인을 다음과 같이 분해할 수 있습니다. 애플리케이션 프로세스와 애플리케이션 사이에 매우 간단한 API를 제공합니다. 합의 과정.
مقدمة
النجاح المشترك للنظام البيئي مفتوح المصدر، المشاركة اللامركزية، والعملات المشفرة العامة ألهمت فهم بروتوكولات الإنترنت اللامركزية يمكن استخدامها لتحسين البنية التحتية الاجتماعية والاقتصادية بشكل جذري. لقد رأينا تطبيقات blockchain متخصصة مثل Bitcoin [1] (أ العملة المشفرة)، Zerocash [2] (عملة مشفرة للخصوصية)، و منصات smart contract المعممة مثل Ethereum [3]، مع عدد لا يحصى من التطبيقات الموزعة لـ Etherium Virtual الآلة (EVM) مثل Augur (سوق التنبؤ) وTheDAO [4] (نادي استثماري). ومع ذلك، حتى الآن، عانى هؤلاء blockchain من عدد من المشاكل من العيوب، بما في ذلك عدم كفاءة الطاقة الإجمالية، أو الفقراء أو الأداء المحدود، وآليات الحوكمة غير الناضجة. مقترحات لتوسيع نطاق معاملات Bitcoin، مثل الشاهد المنفصل [5] و BitcoinNG [6]، عبارة عن مقياس رأسي الحلول التي تظل محدودة بقدرة جسدية واحدة الآلة، وذلك لضمان خاصية المراجعة الكاملة. يمكن أن تساعد الشبكة المسرّعة [7] في توسيع نطاق المعاملات Bitcoin
الحجم عن طريق ترك بعض المعاملات خارج دفتر الأستاذ تمامًا، وهو مناسب تمامًا للمدفوعات الصغيرة والحفاظ على الخصوصية قضبان الدفع، ولكنها قد لا تكون مناسبة لمزيد من التعميم احتياجات التحجيم. الحل المثالي هو الذي يسمح بتعدد blockchains المتوازية التفاعل مع الاحتفاظ بخصائصها الأمنية. هذا قد ثبت أنه صعب، إن لم يكن مستحيلاً، مع proof-of-work. تم الدمج التعدين، على سبيل المثال، يسمح بالعمل المنجز لتأمين أحد الوالدين السلسلة ليتم إعادة استخدامها في سلسلة فرعية، ولكن يجب أن تظل المعاملات كذلك تم التحقق من صحتها، بالترتيب، بواسطة كل عقدة، وتم الدمج blockchain يكون عرضة للهجوم إذا كانت أغلبية hashing السلطة على لا يقوم الوالد بدمج تعدين الطفل بشكل نشط. مراجعة أكاديمية يتم توفير بنيات الشبكة البديلة blockchain سياق إضافي، ونقدم ملخصات للمقترحات الأخرى وعيوبها في الأعمال ذات الصلة. نقدم هنا Cosmos، بنية شبكة جديدة blockchain الذي يعالج كل هذه المشاكل. Cosmos عبارة عن شبكة تضم الكثيرين blockchains مستقلة، تسمى المناطق. يتم تشغيل المناطق بواسطة Tendermint Core [8]، والذي يوفر أداءً عاليًا، محرك إجماع متسق وآمن يشبه PBFT، حيث تضمن المساءلة الصارمة للفرعية التحكم في سلوك البرامج الضارة الجهات الفاعلة. تعتبر خوارزمية الإجماع BFT الخاصة بـ Tendermint Core مناسبة تمامًا لتوسيع النطاق العام proof-of-stake blockchains. المنطقة الأولى في Cosmos تسمى Cosmos Hub. Cosmos Hub عبارة عن عملة مشفرة متعددة الأصول proof-of-stake ذات قيمة بسيطة آلية الحوكمة التي تمكن الشبكة من التكيف و ترقية. بالإضافة إلى ذلك، يمكن تمديد المحور Cosmos بواسطة ربط مناطق أخرى. يتواصل مركز ومناطق شبكة Cosmos معها بعضهما البعض عبر بروتوكول اتصال inter-blockchain (IBC)، نوع UDP أو TCP افتراضي لـ blockchains. يمكن أن تكون الرموز يتم نقلها من منطقة إلى أخرى بشكل آمن وسريعدون الحاجة إلى سيولة التبادل بين المناطق. بدلا من ذلك، جميع عمليات النقل بين المناطق token تمر عبر مركز Cosmos، والذي يتتبع المبلغ الإجمالي لـ tokens الذي تحتفظ به كل منطقة. ال يعزل المحور كل منطقة عن فشل المناطق الأخرى. لان يمكن لأي شخص توصيل منطقة جديدة بمركز Cosmos، كما تسمح المناطق بذلك من أجل التوافق المستقبلي مع ابتكارات blockchain الجديدة. في هذا القسم نصف بروتوكول توافق Tendermint والواجهة المستخدمة لبناء التطبيقات بها. للمزيد التفاصيل، انظر الملحق. في الخوارزميات البيزنطية الكلاسيكية المتسامحة مع الأخطاء (BFT)، كل عقدة له نفس الوزن. في Tendermint، العقد لها قيمة غير سلبية مقدار قوة التصويت، والعقد التي لها تصويت إيجابي تسمى الطاقة validators. يشارك المصادقون في بروتوكول الإجماع عن طريق بث التوقيعات المشفرة، أو الأصوات، للاتفاق على الكتلة التالية. يتم تحديد صلاحيات التصويت للمصادقين عند النشأة، أو يتم تحديدها تم تغييره بشكل حتمي بواسطة blockchain، اعتمادًا على application. على سبيل المثال، في تطبيق proof-of-stake مثل مركز Cosmos، قد يتم تحديد قوة التصويت بواسطة مبلغ staking tokens مرهون كضمان. ملاحظة: تشير الكسور مثل ⅔ و⅓ إلى أجزاء من إجمالي التصويت الطاقة، لا العدد الإجمالي لـ validators أبدًا، ما لم يكن كل validators لها وزن متساوي. >⅔ تعني "أكثر من ⅔"، ≥⅓ تعني "على الأقل". ⅓". Tendermint هو بروتوكول إجماع BFT متزامن جزئيًا مشتقة من خوارزمية إجماع DLS [20]. النعناع هو
يتميز ببساطته وأدائه ومسؤوليته. يتطلب البروتوكول مجموعة yxed المعروفة من validators، حيث يكون كل منها يتم التعرف على validator بواسطة مفتاحهم العام. يحاول المدققون القيام بذلك التوصل إلى توافق في الآراء بشأن كتلة واحدة في كل مرة، حيث تكون الكتلة عبارة عن قائمة من المعاملات. يستمر التصويت للتوافق على الكتلة جولات. كل جولة لها قائد مستدير أو مقترح يقترح كتلة. ثم يصوت validators، على مراحل، على ما إذا كان ذلك أم لا لقبول الكتلة المقترحة أو الانتقال إلى الجولة التالية. ال يتم اختيار مقدم العرض للجولة بشكل حتمي من الأمر قائمة validators، بما يتناسب مع قوة التصويت الخاصة بهم. يتم وصف التفاصيل الكاملة للبروتوكول هنا. أمان Tendermint مستمد من استخدامه للبيزنطية المثالية التسامح مع الخطأ من خلال التصويت بالأغلبية العظمى (>⅔) والقفل آلية. ويضمنون معًا ما يلي: ≥⅓ قوة التصويت يجب أن تكون بيزنطية للتسبب في انتهاك السلامة، حيث يتم الالتزام بأكثر من قيمتين. إذا نجحت أي مجموعة من validators في انتهاك السلامة، أو حتى محاولات القيام بذلك، يمكن التعرف عليهم من خلال البروتوكول. هذا يشمل كلا من التصويت للكتل conzicting والبث أصوات غير مبررة على الرغم من ضماناته القوية، يقدم Tendermint منتجات استثنائية الأداء. في معايير 64 عقدة موزعة على 7 مراكز البيانات في 5 قارات، في المثيلات السحابية للسلع الأساسية، يمكن لتوافق Tendermint معالجة آلاف المعاملات لكل ثانيًا، مع فترات استجابة للالتزام تتراوح من ثانية إلى ثانيتين. والجدير بالذكر أن أداء ما يزيد عن ألف معاملة لكل يتم الحفاظ على الثانية حتى في ظروف الخصومة القاسية validators يعطل أو يبث أصواتًا ضارة. انظر ygur أدناه للحصول على التفاصيل.
تم تبسيط إحدى المزايا الرئيسية لخوارزمية الإجماع الخاصة بـ Tendermint أمان العميل الخفيف، مما يجعله مرشحًا مثاليًا للهواتف المحمولة و حالات استخدام إنترنت الأشياء. بينما يجب على العميل الخفيف Bitcoin المزامنة سلاسل رؤوس الكتل والسلسلة التي تحتوي على أكبر دليل على ذلك في العمل، يحتاج عملاء Tendermint Light فقط إلى مواكبة التغييرات إلى مجموعة validator، ثم تحقق من >⅔ PreCommits في أحدث كتلة لتحديد أحدث حالة. تعمل أيضًا أدلة العميل الخفيفة المقتضبة على تمكين inter-blockchain الاتصالات. لدى Tendermint إجراءات وقائية لمنع حدوث بعض الأمراض الهجمات الملحوظة، مثل عمليات الإنفاق المزدوجة بعيدة المدى التي لا تنطوي على أي شيء على المحك والرقابة. وتناقش هذه بشكل كامل في الملحق.يتم تنفيذ خوارزمية إجماع Tendermint في ملف برنامج يسمى Tendermint الأساسية. Tendermint Core هو "محرك الإجماع" الحيادي للتطبيق والذي يمكنه تشغيل أي تطبيق تطبيق الصندوق الأسود الحتمي في نسخة متماثلة موزعة blockchain. يتصل Tendermint Core بتطبيقات blockchain عبر واجهة Blockchain للتطبيق (ABCI) [17]. وبالتالي، ABCI يسمح ببرمجة تطبيقات blockchain في أي اللغة، وليس فقط لغة البرمجة التي تم الإجماع عليها تمت كتابة المحرك. بالإضافة إلى ذلك، ABCI يجعل من الممكن بسهولة قم بتبديل طبقة الإجماع لأي مكدس blockchain موجود. نرسم تشبيهًا بالعملة المشفرة المعروفة Bitcoin. Bitcoin هي عملة مشفرة blockchain حيث تحتفظ كل عقدة قاعدة بيانات لمخرجات المعاملات غير المنفقة (UTXO) المدققة بالكامل. إذا أراد أحدهم إنشاء نظام يشبه Bitcoin أعلى ABCI، سيكون Tendermint Core مسؤولاً عن مشاركة الكتل والمعاملات بين العقد إنشاء ترتيب قانوني/غير قابل للتغيير للمعاملات ( blockchain) وفي الوقت نفسه، سيكون تطبيق ABCI مسؤولاً عن ذلك صيانة قاعدة البيانات UTXO التحقق من صحة التوقيعات المشفرة للمعاملات منع المعاملات من صرف أموال غير موجودة السماح للعملاء بالاستعلام عن قاعدة البيانات UTXO Tendermint قادر على تحليل تصميم blockchain بواسطة تقديم واجهة برمجة تطبيقات بسيطة جدًا بين عملية تقديم الطلب و عملية الإجماع.
Cosmos 아키텍처
Cosmos는 독립적인 병렬 blockchain의 네트워크입니다. 각각은 다음과 같은 고전적인 BFT 합의 알고리즘으로 구동됩니다. 텐더민트 1. 이 네트워크의 첫 번째 blockchain은 Cosmos 허브가 됩니다. 는 Cosmos 허브는 다음을 통해 다른 많은 blockchain(또는 영역)에 연결됩니다. 새로운 inter-blockchain 통신 프로토콜. Cosmos 허브 수많은 token 유형을 추적하고 총계를 기록합니다. 연결된 각 영역의 token 수. 토큰은 다음과 같습니다. 한 구역에서 다른 구역으로 안전하고 신속하게 이전됩니다. 구역 간 액체 교환이 필요하지 않습니다. 존 간 코인 전송은 Cosmos 허브를 통해 이루어집니다. 이 아키텍처는 blockchain 공간이 안고 있는 많은 문제를 해결합니다. 애플리케이션 상호 운용성, 확장성 및 원활한 업그레이드. 예를 들어 Bitcoind에서 파생된 영역은 Go-Ethereum, CryptoNote, ZCash 또는 모든 blockchain 시스템은 Cosmos 허브에 연결하세요. 이 영역에서는 Cosmos이(가) 다음을 수행할 수 있습니다. 글로벌 트랜잭션 수요를 충족하기 위해 무한한 확장이 가능합니다. 구역은 또한 다음과 같이 지원될 분산형 교환을 위한 훌륭한 yt입니다. 음. Cosmos는 단순한 분산 원장이 아니며, Cosmos 허브는 벽으로 둘러싸인 정원이나 우주의 중심이 아닙니다. 우리는 분산 원장의 개방형 네트워크를 위한 프로토콜 설계 미래 금융시스템의 새로운 기반이 될 수 있는 암호화 원칙, 건전한 경제, 합의를 바탕으로 이론, 투명성, 책임. Cosmos 허브는 Cosmos의 첫 번째 공개 blockchain입니다. Tendermint의 BFT 합의 알고리즘으로 구동되는 네트워크. 는 Tendermint 오픈 소스 프로젝트는 2014년에 탄생했습니다. Bitcoin 작업 증명 합의 알고리즘의 속도, 확장성 및 환경 문제. 검증된 기술을 활용하고 개선함으로써
BFT 1988년 MIT에서 개발된 알고리즘 [20], Tendermint 팀은 proof-of-stake을 개념적으로 시연한 최초의 팀이었습니다. 무관계 문제를 해결하는 암호화폐 1세대 proof-of-stake 암호화폐로 인해 어려움을 겪고 있습니다. NXT 및 BitShares1.0으로. 오늘날 거의 모든 Bitcoin 모바일 지갑은 신뢰할 수 있는 서버를 사용하여 거래 확인을 제공합니다. 이는 작업 증명이 완료되기 전에 많은 확인을 기다려야 하기 때문입니다. 트랜잭션은 되돌릴 수 없게 커밋된 것으로 간주될 수 있습니다. Doublespend 공격은 다음과 같은 서비스에서 이미 입증되었습니다. 코인베이스. 다른 blockchain 합의 시스템과 달리 Tendermint는 다음을 제공합니다. 즉각적이고 안전한 모바일 클라이언트 결제 확인. Tendermint는 절대 포크되지 않도록 설계되었기 때문에 모바일에서는 지갑은 즉시 거래 확인을 받을 수 있습니다. 신뢰할 수 없고 실용적인 결제가 스마트폰에서 현실이 되었습니다. 이 다음과 같이 사물 인터넷 애플리케이션에 상당한 영향을 미치고 있습니다. 음. Cosmos의 검증인은 Bitcoin 채굴자와 비슷한 역할을 가지고 있지만 대신 암호화 서명을 사용하여 투표하세요. 검증인은 커밋을 담당하는 안전한 전용 머신 블록. validator이 아닌 사람은 자신의 staking token(라고 함)을 위임할 수 있습니다. “atoms”)를 validator에 보내 블록 수수료와 아톰의 일부를 얻으세요 보상을 제공하지만, 다음과 같은 경우 처벌(삭감)을 받을 위험이 있습니다. 대리인 validator이(가) 해킹당하거나 프로토콜을 위반합니다. 입증된 Tendermint BFT 합의의 안전 보장 및 담보 이해관계자 예치금–validators 및 위임자–제공 노드와 라이트 클라이언트를 위한 입증 가능하고 수량화 가능한 보안. 분산 공공 원장은 헌법과 거버넌스 시스템. Bitcoin은(는) Bitcoin 재단에 의존하며업그레이드를 조정하기 위해 마이닝을 수행하지만 이는 느린 프로세스입니다. Ethereum 주소를 하드포크한 후 ETH와 ETC로 분할 DAO 해킹, 주로 사전 사회 계약이 없었기 때문입니다. 그러한 결정을 내리는 메커니즘도 없습니다. Cosmos 허브의 검증인과 위임자는 투표할 수 있습니다. 시스템의 미리 설정된 매개변수를 변경할 수 있는 제안 자동으로(예: 블록 가스 한도) 업그레이드 조정 인간이 읽을 수 있는 헌법 개정안에 투표할 수도 있습니다. Cosmos 허브의 정책을 관리합니다. 헌법 다음과 같은 문제에 대해 이해관계자 간의 결속력을 허용합니다. 도난 및 버그(예: TheDAO 사건)를 방지하여 더 빠르고 더 깨끗한 해상도. 각 영역은 자체 구성과 거버넌스를 가질 수도 있습니다. 메커니즘도 그렇고. 예를 들어, Cosmos 허브에는 허브에서 불변성을 강제하는 헌법(롤백 없음, Cosmos 허브 노드 구현의 버그를 위해 저장) 각 영역은 롤백과 관련된 자체 정책을 설정할 수 있습니다. 서로 다른 정책 영역 간의 상호 운용성을 가능하게 함으로써 Cosmos 네트워크는 사용자에게 궁극적인 자유와 잠재력을 제공합니다. 무허가 실험. 여기서 우리는 분산화와 확장성의 새로운 모델을 설명합니다. Cosmos는 다음을 기반으로 하는 많은 blockchain의 네트워크입니다. 텐더민트. 기존 제안은 '단일'을 만드는 것을 목표로 하고 있지만 blockchain”(총 글로벌 트랜잭션 주문 포함), Cosmos 많은 blockchain이 서로 동시에 실행되도록 허용합니다. 상호 운용성을 유지하면서. 기본적으로 Cosmos 허브는 많은 독립적인 서비스를 관리합니다. blockchain는 "영역"이라고 합니다(때때로 "샤드"라고도 함). "샤딩"으로 알려진 데이터베이스 확장 기술 참조).
게시된 영역에서 최근 블록 커밋의 지속적인 스트림 허브를 사용하면 허브가 각 영역의 상태를 따라갈 수 있습니다. 마찬가지로 각 영역은 허브의 상태를 따라갑니다(그러나 영역은 간접적인 방법 외에는 서로 연락을 유지하지 마십시오. 허브). 그런 다음 정보 패킷이 한 곳에서 전달됩니다. Merkle 증명을 증거로 게시하여 다른 영역으로 영역을 확장합니다. 정보가 전송되고 수신되었습니다. 이 메커니즘을 inter-blockchain 통신 또는 줄여서 IBC입니다. 모든 영역은 그 자체로 비순환 그래프를 형성하는 허브가 될 수 있습니다. 하지만 명확성을 위해 간단한 내용만 설명하겠습니다. 허브는 하나만 있고 허브가 아닌 많은 구성 구역. Cosmos 허브는 다중 자산을 호스팅하는 blockchain입니다. token을 개인 사용자가 보유할 수 있는 분산 원장 또는 영역 자체별로. 이 token은 하나의 영역에서 이동할 수 있습니다. "코인 패킷"이라고 불리는 특별한 IBC 패킷을 통해 다른 사람에게 전달됩니다. 허브는 전체의 전역 불변성을 보존하는 역할을 담당합니다. 영역 전체에 걸쳐 각 token의 양. IBC 코인 패킷 트랜잭션은 송신자, 허브 및 수신자에 의해 커밋되어야 합니다. blockchains.Cosmos 허브는 전체에 대한 중앙 원장 역할을 하기 때문에 시스템에서는 허브의 보안이 가장 중요합니다. 동안 각 영역은 다음과 같이 보호되는 Tendermint blockchain일 수 있습니다. 4개(또는 BFT 합의가 필요하지 않은 경우 더 적음), 허브 전 세계적으로 분산된 validator 세트로 보호되어야 합니다. 다음과 같은 가장 심각한 공격 시나리오를 견딜 수 있습니다. 대륙 네트워크 분할 또는 국가 후원 공격. Cosmos 영역은 IBC를 교환하는 독립적인 blockchain입니다. 허브와의 메시지. 허브의 관점에서 구역은 다중 자산 동적 멤버십 다중 서명 계정 IBC 패킷을 사용하여 token을 보내고 받을 수 있습니다. 처럼 암호화폐 계정, 영역은 다음보다 더 많은 token을 전송할 수 없습니다. 가지고 있지만 그것을 가지고 있는 다른 사람으로부터 token을(를) 받을 수 있습니다. A 구역 하나 이상의 token 유형의 "소스"로 지정될 수 있습니다. token 공급량을 주입할 수 있는 권한을 부여합니다. Cosmos 허브의 아톰은 영역의 validator에 스테이킹될 수 있습니다. 허브에 연결되었습니다. 이 영역에 대한 이중 지출 공격이 발생하는 동안 투표권의 ⅔ 이상이 있는 영역인 Tendermint의 포크 책임으로 인해 원자가 삭감될 수 있습니다. 비잔틴은 잘못된 상태를 커밋할 수 있습니다. Cosmos 허브는 그렇지 않습니다 다른 영역에서 커밋된 트랜잭션을 확인하거나 실행하므로 신뢰할 수 있는 영역에 token을 보내는 것은 사용자의 책임입니다. 앞으로 Cosmos 허브의 거버넌스 시스템은 허브를 통과할 수 있습니다. 영역 오류를 설명하는 개선 제안. 에 대한 예를 들어 일부(또는 전체) 영역에서 아웃바운드 token 전송이 발생할 수 있습니다. 구역의 비상 회로 차단을 허용하도록 조절됩니다. (token 전송이 일시적으로 중단됨) 공격이 감지되면 이제 허브와 영역이 서로 통신하는 방법을 살펴보겠습니다. 기타. 예를 들어 blockchain이 3개 있는 경우 "Zone1", "Zone2",
그리고 “Hub”, 그리고 우리는 “Zone1”이 목적지로 향하는 패킷을 생성하기를 원합니다. “Hub”를 통과하는 “Zone2”에 대해. 한 곳에서 패킷을 이동하려면 blockchain 다른 사람에게 증거가 수신 체인에 게시됩니다. 증거는 전송 체인이 다음을 위한 패킷을 게시했음을 나타냅니다. 목적지 추정. 수신 체인이 이 증명을 확인하려면 발신자의 블록 헤더를 따라갈 수 있어야 합니다. 이 메커니즘은 사이드체인에서 사용되는 것과 유사합니다. 두 개의 상호 작용하는 체인은 다음을 통해 서로를 인식합니다. 존재 증명 데이터그램의 양방향 스트림 (거래). IBC 프로토콜은 두 가지 유형의 프로토콜을 사용하여 자연스럽게 비활성화될 수 있습니다. 트랜잭션: IBCBlockCommitTx 트랜잭션을 허용합니다. blockchain는 가장 최근 블록-hash의 관찰자에게 증명하기 위해, 및 IBCPacketTx 트랜잭션을 통해 blockchain을(를) 수행할 수 있습니다. 주어진 패킷이 실제로 게시되었음을 모든 관찰자에게 증명합니다. 발신자의 신청에 따라 Merkle-proof을 통해 최근 블록-hash. IBC 메커니즘을 두 개의 개별 트랜잭션으로 분할함으로써 우리는 수신 체인의 기본 수수료 시장 메커니즘을 허용합니다. 어떤 패킷이 커밋(즉, 승인)되는지 결정합니다. 전송 체인에 대해 완전한 자유를 허용합니다. 많은 아웃바운드 패킷이 허용됩니다. 위의 예에서는 "Zone1"의 블록-hash을 업데이트하기 위해 '허브'(또는 'Zone2'의 '허브')에서 IBCBlockCommitTx거래는 블록-hash과 함께 "허브"에 게시되어야 합니다. “Zone1”(또는 “Hub”의 블록이 hash인 “Zone2”). 자세한 내용은 IBCBlockCommitTx 및 IBCPacketTx를 참조하세요. 두 가지 IBC 거래 유형에 대해 Bitcoin이 분산되어 있어 더 안전한 것과 마찬가지로, 대량 복제 원장을 사용하면 교환의 취약성을 줄일 수 있습니다. blockchain에서 실행하여 외부 및 내부 해킹을 수행합니다. 우리 이것을 분산 교환이라고 부릅니다. 암호화폐 커뮤니티가 분산화라고 부르는 것 오늘날의 거래소는 "원자 교차 체인"(AXC) 거래를 기반으로 합니다. AXC 트랜잭션을 사용하면 두 명의 사용자가 두 개의 다른 체인은 두 개의 전송 트랜잭션을 만들 수 있습니다. 두 원장 모두에 함께 커밋되거나 전혀 커밋되지 않습니다(예: 원자적으로). 예를 들어, 두 명의 사용자가 비트코인을 이더(또는 두 개의 서로 다른 원장에 있는 두 개의 token) AXC 트랜잭션을 사용하여 Bitcoin 및 Ethereum이 각각 연결되어 있지 않더라도 기타. AXC 거래에서 거래소를 운영하면 얻을 수 있는 이점은 다음과 같습니다. 두 사용자 모두 서로를 신뢰하거나 거래 매칭을 신뢰할 필요가 없습니다. 서비스. 단점은 양측 모두 온라인 상태여야 한다는 것입니다. 거래가 발생합니다. 또 다른 유형의 탈중앙화 거래소는 대량 복제 거래소입니다. 자체적으로 실행되는 분산 교환 blockchain. 사용자 이러한 종류의 교환은 지정가 주문을 제출하고 전환할 수 있습니다. 컴퓨터가 꺼져 있으면 사용자가 없어도 거래가 실행될 수 있습니다. 온라인. blockchain이(가) 대신하여 거래를 일치시키고 완료합니다. 상인의.
Cosmos الهندسة المعمارية
Cosmos عبارة عن شبكة متوازية مستقلة blockchains كل منها مدعوم بخوارزميات الإجماع الكلاسيكية BFT مثل النعناع 1. سيكون blockchain الأول في هذه الشبكة هو Cosmos Hub. ال Cosmos يتصل المحور بالعديد من blockchains (أو المناطق) عبر بروتوكول اتصال جديد بين blockchain. المركز Cosmos يتتبع العديد من أنواع token ويحتفظ بسجل للمجموع عدد tokens في كل منطقة متصلة. يمكن أن تكون الرموز يتم نقلها من منطقة إلى أخرى بشكل آمن وسريع دون الحاجة إلى تبادل السوائل بين المناطق، لأن جميعها تتم عمليات تحويل العملات بين المناطق عبر مركز Cosmos. تعمل هذه البنية على حل العديد من المشكلات المتعلقة بمساحة blockchain يواجه اليوم، مثل قابلية التشغيل البيني للتطبيقات، وقابلية التوسع، و إمكانية الترقية السلسة. على سبيل المثال، المناطق المشتقة من Bitcoind، يمكنك الانتقال إلى Ethereum أو CryptoNote أو ZCash أو أي نظام blockchain يتم توصيله بمركز Cosmos. تسمح هذه المناطق لـ Cosmos بذلك التوسع بشكل لا نهائي لتلبية الطلب على المعاملات العالمية. المناطق هي أيضا يعد خيارًا رائعًا للتبادل الموزع، والذي سيتم دعمه كـ حسنا. Cosmos ليس مجرد دفتر أستاذ موزع، وCosmos Hub ليس حديقة مسورة أو مركز الكون. نحن كذلك تصميم بروتوكول لشبكة مفتوحة من دفاتر الأستاذ الموزعة والتي يمكن أن تكون بمثابة أساس جديد للأنظمة المالية المستقبلية، على أساس مبادئ التشفير والاقتصاد السليم والإجماع النظرية والشفافية والمساءلة. يعد مركز Cosmos هو المركز العام الأول blockchain في Cosmos الشبكة، مدعومة بخوارزمية الإجماع BFT الخاصة بـ Tendermint. ال تم إنشاء مشروع Tendermint مفتوح المصدر في عام 2014 لمعالجة المشكلة السرعة وقابلية التوسع والمشكلات البيئية المتعلقة بخوارزمية إجماع إثبات العمل الخاصة بـ Bitcoin. باستخدام وتحسين ما ثبت
BFT خوارزميات تم تطويرها في معهد ماساتشوستس للتكنولوجيا في عام 1988 [20]، Tendermint كان الفريق أول من قدم عرضًا مفاهيميًا لـ proof-of-stake عملة مشفرة تعالج مشكلة عدم وجود شيء على المحك عانى الجيل الأول من العملات المشفرة proof-of-stake مثل مثل NXT وBitShares1.0. اليوم، تستخدم جميع محافظ الهاتف المحمول Bitcoin تقريبًا خوادم موثوقة تزويدهم بالتحقق من المعاملة. وذلك لأن إثبات العمل يتطلب انتظار العديد من التأكيدات قبل يمكن اعتبار المعاملة ملتزمة بشكل لا رجعة فيه. لقد تم بالفعل عرض هجمات Doublespend على خدمات مثل CoinBase. على عكس أنظمة الإجماع blockchain الأخرى، تقدم Tendermint التحقق من الدفع عبر الهاتف المحمول بشكل فوري وآمن. نظرًا لأن Tendermint مصمم بحيث لا يتشعب أبدًا على الإطلاق، فهو متنقل يمكن أن تتلقى المحافظ تأكيدًا فوريًا للمعاملات، مما يجعل المدفوعات غير الموثوقة والعملية حقيقة واقعة على الهواتف الذكية. هذا له تأثيرات كبيرة على تطبيقات إنترنت الأشياء مثل حسنا. يتمتع المدققون في Cosmos بدور مماثل لعمال المناجم Bitcoin، ولكن بدلاً من ذلك استخدم التوقيعات المشفرة للتصويت. المصادقون هم آلات آمنة ومخصصة مسؤولة عن الالتزام كتل. يمكن لغير validators تفويض staking tokens (يُسمى "الذرات") إلى أي validator لكسب جزء من رسوم الكتلة والذرة المكافآت، لكنهم يتعرضون لخطر العقاب (القطع) إذا تم اختراق المندوب validator أو انتهاك البروتوكول. ثبت ضمانات سلامة Tendermint BFT الإجماع والضمانات إيداع أصحاب المصلحة – validator والمفوضين – تقديم أمان يمكن إثباته وقابل للقياس للعقد والعملاء الخفيفين. يجب أن تحتوي الدفاتر العامة الموزعة على دستور و نظام الحكم. Bitcoin يعتمد على Bitcoin الأساس والتعدين لتنسيق الترقيات، ولكن هذه عملية بطيئة. تم تقسيم Ethereum إلى ETH وETC بعد التفرع الصعب للمعالجة يعود سبب الاختراق DAO إلى حد كبير إلى عدم وجود عقد اجتماعي مسبق ولا آلية لاتخاذ مثل هذه القرارات. يمكن للمصادقين والمفوضين في Cosmos التصويت عليهم المقترحات التي يمكن أن تغير المعلمات المحددة مسبقًا للنظام تلقائيا (مثل حد الغاز كتلة)، وتنسيق الترقيات، كما وكذلك التصويت على تعديلات الدستور الذي يمكن قراءته بواسطة الإنسان التي تحكم سياسات Cosmos Hub. الدستور يسمح بالتماسك بين أصحاب المصلحة بشأن قضايا مثل السرقة والأخطاء (مثل حادثة DAO)، مما يسمح بإجراء أسرع وأسرع دقة أنظف. يمكن أن يكون لكل منطقة أيضًا دستورها ونظام حكمها الخاص آلية كذلك. على سبيل المثال، يمكن أن يحتوي المركز Cosmos على الدستور الذي يفرض الثبات في المركز (لا يوجد تراجع، حفظ الأخطاء في تنفيذ العقدة المركزية Cosmos)، بينما يمكن لكل منطقة وضع سياساتها الخاصة فيما يتعلق بالتراجع. ومن خلال تمكين إمكانية التشغيل البيني بين مناطق السياسة المختلفة، فإن تمنح شبكة Cosmos مستخدميها الحرية المطلقة والإمكانات تجريب غير مسموح به. نحن هنا نصف نموذجًا جديدًا للامركزية وقابلية التوسع. Cosmos عبارة عن شبكة تضم العديد من blockchains التي يتم تشغيلها بواسطة النعناع. بينما تهدف المقترحات الحالية إلى إنشاء "فردية". blockchain" مع إجمالي طلب المعاملات العالمية، Cosmos يسمح للعديد من blockchains بالعمل بشكل متزامن مع بعضها البعض مع الاحتفاظ بإمكانية التشغيل البيني. في الأساس، يدير Cosmos Hub العديد من المستقلين blockchains تسمى "المناطق" (يشار إليها أحيانًا باسم "الأجزاء"، في إشارة إلى تقنية قياس قاعدة البيانات المعروفة باسم "التقسيم").
دفق مستمر من عمليات الحظر الأخيرة من المناطق المنشورة عليها يسمح Hub للمركز بمواكبة حالة كل منطقة. وبالمثل، فإن كل منطقة تواكب حالة المحور (لكن المناطق لا يواكبون بعضهم البعض إلا بشكل غير مباشر من خلال المحور). ثم يتم إرسال حزم المعلومات من واحدة منطقة إلى أخرى عن طريق نشر أدلة Merkle كدليل على أن تم إرسال المعلومات واستلامها. وتسمى هذه الآلية التواصل بين blockchain، أو IBC للاختصار. يمكن لأي من المناطق أن تكون في حد ذاتها محاورًا لتكوين رسم بياني غير دوري، ولكن من أجل الوضوح سنصف فقط ما هو بسيط conyguration حيث لا يوجد سوى محور واحد، والعديد من غير المحور المناطق. مركز Cosmos هو blockchain الذي يستضيف أصولًا متعددة دفتر الأستاذ الموزع، حيث يمكن الاحتفاظ بـ tokens بواسطة مستخدمين فرديين أو حسب المناطق نفسها. يمكن نقل هذه tokens من منطقة واحدة إلى أخرى في حزمة خاصة IBC تسمى "حزمة العملات المعدنية". المحور هو مسؤولة عن الحفاظ على الثبات العالمي للمجموع مقدار كل token عبر المناطق. IBC حزمة العملات المعدنية يجب أن يتم تنفيذ المعاملات من قبل المرسل والمركز والمتلقي blockchains.نظرًا لأن Cosmos Hub يعمل بمثابة دفتر الأستاذ المركزي للكل النظام، فإن أمن المركز له أهمية قصوى. بينما قد تكون كل منطقة عبارة عن Tendermint blockchain مؤمنة بواسطة as عدد قليل يصل إلى 4 (أو حتى أقل إذا لم يكن هناك حاجة إلى إجماع BFT)، المحور يجب تأمينها من خلال مجموعة لامركزية عالميًا من validators يمكن أن تصمد أمام سيناريوهات الهجوم الأكثر خطورة، مثل تقسيم الشبكة القارية أو هجوم ترعاه الدولة القومية. منطقة Cosmos هي منطقة blockchain مستقلة تتبادل IBC الرسائل مع المحور. من وجهة نظر المحور، المنطقة هي أ حساب متعدد التوقيع للعضوية الديناميكية المتعددة الأصول يمكن إرسال واستقبال tokens باستخدام IBC الحزم. مثل أ حساب العملة المشفرة، لا يمكن للمنطقة نقل أكثر من tokens من إنه موجود بالفعل، ولكن يمكنه تلقي tokens من الآخرين الذين لديهم تلك الرسائل. منطقة قد يتم تعيينه كـ "مصدر" لواحد أو أكثر من أنواع token، ومنحها القدرة على تعزيز هذا العرض token. قد يتم تثبيت ذرات المركز Cosmos بواسطة validators في المنطقة متصل بالمحور. بينما تشن الهجمات المزدوجة الإنفاق على هذه المناطق من شأنه أن يؤدي إلى خفض الذرات مع المسؤولية الجزئية لـ Tendermint، وهي منطقة حيث يكون >⅔ من قوة التصويت يمكن للبيزنطيين ارتكاب حالة باطلة. مركز Cosmos لا يفعل ذلك التحقق من أو تنفيذ المعاملات المرتكبة في مناطق أخرى، لذلك هو عليه مسؤولية المستخدمين عن إرسال tokens إلى المناطق التي يثقون بها. في المستقبل، قد يجتاز نظام إدارة Cosmos Hub Hub مقترحات التحسين التي تفسر فشل المنطقة. ل على سبيل المثال، قد تكون عمليات النقل الصادرة token من بعض (أو جميع) المناطق يتم خنقها للسماح بقطع دائرة الطوارئ للمناطق (وقف مؤقت لعمليات نقل token) عند اكتشاف هجوم. الآن ننظر إلى كيفية تواصل المركز والمناطق مع كل منهما أخرى. على سبيل المثال، إذا كان هناك ثلاثة blockchains، "Zone1"، "Zone2"،
و"Hub"، ونتمنى أن تقوم "Zone1" بإنتاج حزمة متجهة بالنسبة لـ "Zone2" التي تمر عبر "Hub". لنقل حزمة من واحد blockchain إلى آخر، يتم نشر إثبات على سلسلة الاستلام. يشير الدليل إلى أن سلسلة الإرسال نشرت حزمة لـ الوجهة المزعومة لكي تتحقق السلسلة المتلقية من هذا الإثبات، يجب عليها يجب أن يكون قادرًا على مواكبة رؤوس كتلة المرسل. هذا الآلية مشابهة لتلك المستخدمة في السلاسل الجانبية، الأمر الذي يتطلب سلسلتين متفاعلتين لتكون على علم ببعضهما البعض عبر أ تيار ثنائي الاتجاه من مخططات بيانات إثبات الوجود (المعاملات). من الطبيعي أن يتم فك بروتوكول IBC باستخدام نوعين من المعاملات: معاملة IBCBlockCommitTx ، والتي تسمح بـ blockchain لإثبات لأي مراقب أحدث كتلة لها-hash، ومعاملة IBCPacketTx، والتي تسمح لـ blockchain بـ أثبت لأي مراقب أن الحزمة المحددة قد تم نشرها بالفعل عن طريق تطبيق المرسل، عبر خاصية Merkle-proof للأحدث كتلة-hash. من خلال تقسيم آليات IBC إلى معاملتين منفصلتين، فإننا السماح لآلية سوق الرسوم المحلية لسلسلة الاستقبال بذلك تحديد الحزم التي سيتم الالتزام بها (أي تم الاعتراف بها)، بينما السماح بالحرية الكاملة لسلسلة الإرسال فيما يتعلق بكيفية ذلك يُسمح بالعديد من الحزم الصادرة. في المثال أعلاه، من أجل تحديث الكتلة-hash الخاصة بـ "Zone1" على "Hub" (أو "Hub" في "Zone2")، IBCBlockCommitTxيجب نشر المعاملة على "المركز" مع الكتلة-hash من "Zone1" (أو على "Zone2" مع الكتلة-hash من "Hub"). راجع IBCBlockCommitTx وIBCPacketTx لمزيد من المعلومات على نوعي المعاملات IBC. بنفس الطريقة التي يكون بها Bitcoin أكثر أمانًا من خلال كونه موزعًا، يمكننا أن نجعل التبادلات أقل عرضة للخطر اختراقات خارجية وداخلية عن طريق تشغيله على blockchain. نحن نسمي هذا التبادل الموزع. ما يسميه مجتمع العملات المشفرة اللامركزية تعتمد البورصة اليوم على ما يسمى معاملات "السلسلة الذرية" (AXC). مع معاملة AXC، هناك مستخدمان قيد التشغيل يمكن لسلسلتين مختلفتين إجراء معاملتي تحويل ملتزمة معًا في كلا الدفترين، أو لا شيء على الإطلاق (أي: ذرياً). على سبيل المثال، يمكن لاثنين من المستخدمين تداول عملات البيتكوين مقابل الأثير (أو أي اثنين من tokens في دفتري أستاذ مختلفين) باستخدام معاملات AXC، على الرغم من أن Bitcoin وEthereum غير متصلين ببعضهما أخرى. إن فائدة تشغيل البورصة على معاملات AXC هي أنه لا يحتاج المستخدمون إلى الثقة ببعضهم البعض أو في مطابقة التجارة الخدمة. الجانب السلبي هو أن كلا الطرفين يجب أن يكونا متصلين بالإنترنت التجارة أن تحدث. نوع آخر من التبادل اللامركزي هو التبادل الجماعي التبادل الموزع الذي يعمل من تلقاء نفسه blockchain. المستخدمين على يمكن لهذا النوع من التبادل إرسال أمر محدد وتحويله إيقاف تشغيل الكمبيوتر، ويمكن تنفيذ التجارة دون أن يكون المستخدم موجودًا على الانترنت. يطابق blockchain ويكمل التداول نيابةً عنه من التاجر.
응용
중앙 집중식 거래소는 한도가 높은 주문서를 생성할 수 있습니다. 주문을 통해 더 많은 거래자를 유치할 수 있습니다. 유동성이 더 많은 것을 낳습니다 거래소 세계에는 유동성이 있어 강력한 네트워크가 있습니다. 교환의 효과(또는 최소한 승자 독식 효과) 사업. 현재 암호화폐 거래소의 선두주자 24시간 거래량이 2,000만 달러에 달하는 Poloniex이며 2위는 24시간 거래량이 500만 달러인 Bitynex. 이처럼 강력한 네트워크를 고려하면 따라서 AXC 기반 탈중앙화 거래소가 중앙화된 거래소를 통해 거래량을 확보하세요. 분산화를 위해 중앙화된 거래소와 경쟁하려면 거래소가 필요합니다. 지정가 주문이 포함된 심층 주문장을 지원합니다. 분산된 것만 blockchain에서 교환하면 이를 제공할 수 있습니다. Tendermint는 더 빠른 거래에 대한 추가적인 이점을 제공합니다. 커밋합니다. 희생 없이 빠른 동시성을 우선시하여 일관성, Cosmos의 영역은 트랜잭션을 빠르게 동기화할 수 있습니다. 교환 주문 거래와 IBC token 이체 모두 그리고 다른 지역에서. 오늘날 암호화폐 거래소의 상황을 고려하면, Cosmos에 대한 애플리케이션은 분산 교환(일명 Cosmos DEX). 거래 처리 능력은 물론이고 커밋 대기 시간은 중앙 집중식 커밋 대기 시간과 비슷할 수 있습니다. 교환. 거래자는 실행 가능한 지정가 주문을 제출할 수 있습니다. 양측 모두 온라인 상태일 필요 없이 말이죠. 그리고 텐더민트와 함께, Cosmos 허브 및 IBC, 거래자는 자금을 들어오고 나갈 수 있습니다. 다른 구역과의 빠른 교환. 권한 있는 영역은 연결된 token의 소스 역할을 할 수 있습니다. 또 다른 암호화폐. 다리는 관계와 비슷하다 Cosmos 허브와 영역 사이 둘 다 따라잡아야 해 token이 갖고 있는 증거를 확인하기 위해 다른 블록의 최신 블록 하나에서 다른 것으로 옮겨졌습니다. Cosmos의 "브리지 영역" 네트워크는 허브뿐만 아니라 다른 허브도 따라잡습니다.
암호화폐. 교량 구역을 통한 간접 연결은 다음을 허용합니다. 다른 사람들에게 단순하고 불가지론적인 상태를 유지하는 허브의 논리 blockchain 합의 전략(예: Bitcoin의 proof-of-work) 광산. 각 브리지 영역 validator은 Tendermint 기반의 blockchain 특수 ABCI 브리지 앱을 사용하지만 전체 노드도 "원산지" blockchain. 새로운 블록이 원점에서 채굴되면 브릿지 존은 validators는 서명을 통해 커밋된 블록에 동의하게 됩니다. 출발지의 blockchain에 대한 각자의 로컬 보기를 공유합니다. 팁. 교량지역이 출발지에서 대금을 수령한 경우(그리고 해당 사건에서 충분한 동의가 확인된 것으로 합의되었습니다. Ethereum 또는 Bitcoin과 같은 PoW 체인의 해당 해당 잔액으로 브리지존에 계정이 생성됩니다. Ethereum의 경우 브리지 존은 동일하게 공유할 수 있습니다. validator-Cosmos 허브로 설정됩니다. Ethereum 쪽( 원산지), 브릿지 계약을 통해 이더 보유자가 이더를 보낼 수 있습니다. 브리지 계약으로 전송하여 브리지 영역으로 이동 Ethereum. 브릿지 계약을 통해 에테르가 수신되면, 적절한 IBC 패킷이 없으면 이더를 인출할 수 없습니다. 교량 구역으로부터 교량 계약에 의해 수신됩니다. 는 bridge-contract는 bridge-zone의 validator 세트를 추적합니다. Cosmos 허브의 validator 세트와 동일할 수 있습니다. Bitcoin의 경우, 대신에 단일 브리지 계약, 각 UTXO은 임계값 다중 서명 P2SH 공개 스크립트. 의 한계로 인해 P2SH 시스템에서는 서명자가 Cosmos와 동일할 수 없습니다. 허브 validator-세트.브리지 영역의 이더(“브리지 에테르”)는 다음으로 전송될 수 있습니다. 그리고 허브에서, 나중에 트랜잭션으로 파괴됩니다. Ethereum의 특정 출금 주소로 보냅니다. IBC 브리지존에서 트랜잭션이 발생했음을 증명하는 패킷 Ethereum 브리지 계약에 게시되어 에테르를 허용할 수 있습니다. 철회됩니다. Bitcoin의 경우 제한된 스크립팅 시스템으로 인해 IBC 코인 전송 메커니즘을 반영하기 위해 difycult를 사용하세요. 각 UTXO 자체 독립적인 출판물이 있으므로 모든 UTXO은(는) 세트가 변경되면 새로운 UTXO로 마이그레이션되었습니다. Bitcoin 에스크로 서명자. 한 가지 해결책은 압축하고 총 개수를 유지하기 위해 필요에 따라 UTXO 세트의 압축을 풉니다. UTXOs가 다운되었습니다. 이러한 브리지 계약의 위험은 악성 validator 세트입니다. ≥⅓ 비잔틴 투표권으로 인해 포크가 발생하여 이더가 인출될 수 있습니다. 브리지 영역에 브리지 디더를 유지하면서 Ethereum의 브리지 계약에서. 더 나쁜 것은 >⅔ 비잔틴 투표권이 브릿지 컨트랙트에 보낸 사람에게서 이더를 노골적으로 훔칩니다. 브리지 존의 원래 브리지 논리에서 벗어났습니다. 교량을 다음과 같이 설계함으로써 이러한 문제를 해결할 수 있습니다. 전적으로 책임이 있습니다. 예를 들어 허브와 허브의 모든 IBC 패킷 출발지에서는 교량 구역의 승인이 필요할 수 있습니다. 브리지 영역의 모든 상태 전환이 가능하도록 하는 방식 허브나 원본에서 효율적으로 이의를 제기하고 검증합니다. 브리지 계약. 허브와 오리진은 브리지존 validator이 담보를 게시하고 token이 외부로 전송되도록 허용해야 합니다. 브릿지 계약을 연기해야 합니다(그리고 담보를 해제해야 합니다). 충분히 긴 기간) 독립 감사인. 우리는 사양의 디자인을 남겨두고 이 시스템의 구현은 미래로 공개됩니다 Cosmos
Cosmos 허브에서 통과될 개선 제안 거버넌스 시스템. 확장 문제를 해결하는 것은 Ethereum에 대한 공개 문제입니다. 현재 Ethereum 노드는 모든 단일 트랜잭션을 처리하고 또한 모든 상태를 저장합니다. 링크. Tendermint는 Ethereum보다 훨씬 빠르게 블록을 커밋할 수 있기 때문에 proof-of-work, EVM Tendermint 합의로 구동되는 영역 및 브리지 에테르에서 작동하면 더 높은 성능을 제공할 수 있습니다. Ethereum blockchains. 또한 Cosmos 허브 및 IBC 패킷 메커니즘은 임의의 계약 논리를 허용하지 않습니다. 실행 자체는 token 움직임을 조정하는 데 사용될 수 있습니다. 서로 다른 영역에서 실행되는 Ethereum 계약 간, 다음을 통해 token 중심 Ethereum 확장을 위한 기반 제공 샤딩. Cosmos 영역은 다음에서 정의되는 임의의 응용 프로그램 논리를 실행합니다. 영역 수명의 시작이며 잠재적으로 업데이트될 수 있습니다. 시간이 지남에 따라 거버넌스에 의해. 이러한 zexibility를 통해 Cosmos 영역은 다음을 수행할 수 있습니다. Ethereum와 같은 다른 암호화폐에 대한 브리지 역할을 하거나 Bitcoin 및 해당 blockchain의 파생 상품도 허용합니다. 동일한 코드베이스를 활용하지만 다른 validator 세트와 초기 배포. 이는 기존의 많은 암호화폐를 허용합니다. Ethereum, Zerocash, Bitcoin와 같은 프레임워크, CryptoNote 등이 Tendermint Core와 함께 사용됩니다. 공통 네트워크에서 더 높은 성능의 합의 엔진, 상호 운용성을 위한 엄청난 기회를 열어줍니다. 플랫폼. 또한 다중 자산 blockchain으로서 단일 트랜잭션에는 여러 개의 입력과 출력이 포함될 수 있습니다. 입력은 token 유형이 될 수 있으며, Cosmos을 직접 사용할 수 있습니다. 주문이 가정되지만 분산형 교환을 위한 플랫폼다른 플랫폼을 통해 매칭됩니다. 또는 영역이 게재될 수 있습니다. 분산된 내결함성 교환(주문서 포함)으로, 기존 중앙 집중식에 비해 크게 개선될 수 있습니다. 시간이 지남에 따라 해킹당하는 경향이 있는 암호화폐 거래소. 영역은 blockchain 지원되는 엔터프라이즈 버전으로도 사용할 수 있습니다. 특정 서비스의 일부가 전통적으로 조직이나 조직 그룹에 의해 운영됩니다. 대신 특정 영역에서 ABCI 애플리케이션으로 실행됩니다. 대중의 보안과 상호 운용성을 상속할 수 있습니다. Cosmos 네트워크에 대한 제어권을 희생하지 않고 서비스. 따라서 Cosmos은 두 세계의 장점을 모두 제공할 수 있습니다. blockchain 기술을 활용하려고 하지만 실제로는 그렇지 않은 조직 분산된 제3자에게 통제권을 완전히 양도하는 것을 조심하세요. 파티. 일부에서는 일관성을 선호하는 데 큰 문제가 있다고 주장합니다. Tendermint와 같은 합의 알고리즘은 모든 네트워크에서
⅔인 단일 파티션이 없게 만드는 파티션 투표권(예: ≥⅓이 진에 참여)은 합의를 완전히 중단시킵니다. Cosmos 아키텍처는 다음을 사용하여 이 문제를 완화하는 데 도움이 될 수 있습니다. 투표권이 있는 지역 자치 구역을 갖춘 글로벌 허브 각 영역에 대해 공통 지리적 기반을 기반으로 배포됩니다. 지역. 예를 들어, 공통 패러다임은 개인에 대한 것일 수 있습니다. 도시나 지역을 공유하면서 자체 존을 운영할 수 있습니다. 공통 허브(예: Cosmos 허브)를 통해 지방자치 활동을 가능하게 합니다. 임시 네트워크로 인해 허브가 중단되는 경우에도 지속됩니다. 파티션. 이는 실제 지질학적, 정치적, 견고한 설계 시 고려해야 할 네트워크 토폴로지 특징 연합 내결함성 시스템.
NameCoin은 문제를 해결하려고 시도한 최초의 blockchain 중 하나였습니다. Bitcoin blockchain을 적용하여 이름 확인 문제가 발생했습니다. 불행하게도 이 접근 방식에는 몇 가지 문제가 있었습니다. Namecoin을 사용하면 예를 들어 @satoshi가 과거 어느 시점에 특정 공개 키로 등록된 경우 하지만 그 이후 공개 키가 존재했는지 여부는 알 수 없습니다. 마지막 이후 모든 블록을 다운로드하지 않는 한 최근에 업데이트되었습니다. 그 이름의 업데이트. 이는 Bitcoin의 제한 때문입니다. UTXO 트랜잭션 Merkle-ization 모델, 여기서는 트랜잭션(변경 가능한 애플리케이션 상태는 아님)이 Merkle화되었습니다. 블록-hash에 들어갑니다. 이를 통해 존재를 증명할 수 있지만 이후 이름 업데이트가 존재하지 않는다는 것은 증명할 수 없습니다. 그러므로 우리는 알 수 없다. 전체를 신뢰하지 않고 이름의 가장 최근 값을 확실하게 노드를 다운로드하거나 대역폭에 상당한 비용이 발생합니다. 전체 blockchain. NameCoin에 Merkle화된 검색 트리를 구현하더라도, proof-of-work에 대한 종속성은 가벼운 클라이언트 확인을 만듭니다. 문제가 있다. 라이트 클라이언트는 전체 사본을 다운로드해야 합니다. 전체 blockchain(또는 적어도 모든 블록)의 모든 블록에 대한 헤더 이름에 대한 마지막 업데이트 이후의 헤더). 이는 다음을 의미합니다. 대역폭 요구 사항은 시간에 따라 선형적으로 확장됩니다. [21]. 또한 proof-of-work blockchain의 이름 변경 추가 proof-of-work 확인 블록을 기다려야 합니다. Bitcoin에서는 최대 1시간이 걸릴 수 있습니다. Tendermint를 사용하려면 가장 최근 블록인 hash만 있으면 됩니다. validators 정족수(투표권으로)에 의해 서명되었으며 Merkle 이름과 관련된 현재 값에 대한 증거. 이것은 그것을 만든다 간결하고 빠르며 안전한 라이트 클라이언트를 가질 수 있습니다 이름 값 확인. Cosmos에서는 이 개념을 더 확장할 수 있습니다. 각각 Cosmos의 이름 등록 영역은 ".com" 또는 ".org"와 같은 연관된 최상위 도메인(TLD) 이름을 가질 수 있으며 각 이름은
등록 구역은 자체 거버넌스와 등록을 가질 수 있습니다. 규칙.
التطبيقات
يمكن للبورصة المركزية إنشاء سجل أوامر عميق للحدود الأوامر وبالتالي جذب المزيد من المتداولين. السيولة تولد المزيد السيولة في عالم الصرف، وبالتالي هناك شبكة قوية التأثير (أو على الأقل الفائز يأخذ أكبر قدر من التأثير) في التبادل عمل. الزعيم الحالي لتبادل العملات المشفرة اليوم هو Poloniex بحجم تداول على مدار 24 ساعة بقيمة 20 مليون دولار، وفي المركز الثاني Bitynex بحجم تداول على مدار 24 ساعة بقيمة 5 ملايين دولار. ونظرا لهذه الشبكة القوية من غير المرجح أن تقوم البورصات اللامركزية القائمة على AXC بذلك الفوز بالحجم عبر البورصات المركزية. من أجل اللامركزية تبادل للتنافس مع تبادل مركزي، فإنه سوف تحتاج لدعم دفاتر الطلبات العميقة مع أوامر الحد. فقط موزعة التبادل على blockchain يمكن أن يوفر ذلك. يوفر Tendermint فوائد إضافية للمعاملات الأسرع يرتكب. من خلال إعطاء الأولوية للسرعة دون التضحية الاتساق، يمكن للمناطق الموجودة في Cosmos إجراء المعاملات بسرعة - من أجل كلاً من معاملات أوامر الصرف وكذلك IBC token التحويلات إلى ومن مناطق أخرى. بالنظر إلى حالة بورصات العملات المشفرة اليوم، يعد هذا أمرًا رائعًا تطبيق Cosmos هو التبادل الموزع (المعروف أيضًا باسم Cosmos ديكس). القدرة الإنتاجية للمعاملة كذلك يمكن أن يكون وقت استجابة الالتزام مشابهًا لتلك المركزية التبادلات. يمكن للمتداولين تقديم أوامر محددة يمكن تنفيذها دون أن يكون كلا الطرفين متصلين بالإنترنت. ومع تندرمينت، مركز Cosmos وIBC، يمكن للمتداولين نقل الأموال داخل وخارج التبادل من وإلى المناطق الأخرى بسرعة. يمكن أن تعمل المنطقة المميزة كمصدر لـ token من عملة مشفرة أخرى. الجسر يشبه العلاقة بين المركز والمنطقة Cosmos؛ كلاهما يجب أن يواكبا أحدث الكتل للآخر من أجل التحقق من الأدلة التي يمتلكها tokens انتقلت من واحدة إلى أخرى. "منطقة الجسر" على Cosmos تواكب الشبكة المحور بالإضافة إلى الآخر
عملة مشفرة. يسمح الاتجاه غير المباشر عبر منطقة الجسر منطق المحور ليظل بسيطًا ومحايدًا للآخرين blockchain إستراتيجيات الإجماع مثل Bitcoin proof-of-work التعدين. سيتم تشغيل كل منطقة جسر validator بواسطة Tendermint blockchain مع تطبيق جسر خاص ABCI، ولكن أيضًا عقدة كاملة لـ "الأصل" blockchain. عندما يتم استخراج كتل جديدة في الأصل، منطقة الجسر سوف يتوصل validators إلى اتفاق بشأن الكتل الملتزم بها من خلال التوقيع ومشاركة وجهة نظرهم المحلية الخاصة بالأصل blockchain نصيحة. عندما تتلقى منطقة الجسر الدفع على الأصل (و وقد تم الاتفاق على ما يكفي من التأكيدات في هذه القضية لسلسلة PoW مثل Ethereum أو Bitcoin)، المقابلة يتم إنشاء الحساب في منطقة الجسر بهذا الرصيد. في حالة Ethereum، يمكن لمنطقة الجسر مشاركة نفس الشيء validator-تم تعيينه كمركز Cosmos. على الجانب Ethereum ( Origin)، سيسمح عقد الجسر لحاملي الأثير بإرسال الأثير إلى منطقة الجسر عن طريق إرسالها إلى عقد الجسر Ethereum. بمجرد استلام الأثير من خلال عقد الجسر، فإن لا يمكن سحب الأثير إلا إذا كانت هناك حزمة IBC مناسبة تم استلامها بموجب عقد الجسر من منطقة الجسر. ال يتتبع عقد الجسر مجموعة validator لمنطقة الجسر، والتي قد تكون مطابقة لمجموعة Cosmos Hub validator. في حالة Bitcoin، المفهوم مشابه باستثناء أنه بدلاً من ذلك عقد جسر واحد، سيتم التحكم في كل UTXO بواسطة أ عتبة متعددة التوقيعات P2SH. بسبب القيود في نظام P2SH، لا يمكن أن يكون الموقعون متطابقين مع Cosmos المحور validator-مجموعة.يمكن نقل الأثير الموجود في منطقة الجسر ("الأثير الجسري") إلى ومن المحور، ويتم تدميرها لاحقًا بمعاملة ذلك يرسلها إلى عنوان سحب معين على Ethereum. IBC حزمة تثبت أن المعاملة حدثت في منطقة الجسر يمكن نشرها على عقد الجسر Ethereum للسماح بالأثير ليتم سحبها. في حالة Bitcoin، يقوم نظام البرمجة النصية المقيدة بذلك من الصعب عكس آلية نقل العملة IBC. كل UTXO لديه منشور مستقل خاص به، لذلك يجب أن يكون كل UTXO تم الترحيل إلى UTXO الجديد عندما يكون هناك تغيير في مجموعة Bitcoin موقعي الضمان. أحد الحلول هو الضغط و قم بفك ضغط مجموعة UTXO حسب الضرورة للحفاظ على العدد الإجمالي من UTXOs لأسفل. إن خطر مثل هذا العقد التجسيري هو مجموعة validator المارقة. ≥⅓ يمكن أن تتسبب قوة التصويت البيزنطية في حدوث شوكة وسحب الأثير من عقد الجسر على Ethereum مع الحفاظ على جسر الجسر في منطقة الجسر. والأسوأ من ذلك أن قوة التصويت البيزنطية يمكنها ذلك سرقة الأثير مباشرة من أولئك الذين أرسلوه إلى عقد الجسر بالانحراف عن منطق التجسير الأصلي لمنطقة الجسر. من الممكن معالجة هذه المشكلات من خلال تصميم الجسر مسؤولة تماما. على سبيل المثال، كافة الحزم IBC من المركز و الأصل، قد يتطلب الاعتراف من قبل منطقة الجسر في بهذه الطريقة يمكن أن تكون جميع التحولات الحكومية في منطقة الجسر يتم تحديها والتحقق منها بكفاءة سواء من خلال المركز أو الأصل عقد الجسر. يجب أن يسمح المركز والأصل لمنطقة الجسر validators بنشر الضمانات، وtoken عمليات النقل خارج يجب تأخير عقد الجسر (وفك الضمانات فترة طويلة بما فيه الكفاية) للسماح بأية تحديات مدققين مستقلين. نترك تصميم المواصفات و تنفيذ هذا النظام مفتوح كمستقبل Cosmos
مقترح التحسين، ليتم تمريره من خلال مركز Cosmos نظام الحكم. يعد حل مشكلة القياس مشكلة مفتوحة لـ Ethereum. حاليًا، تقوم عقد Ethereum بمعالجة كل معاملة و أيضا تخزين جميع الدول. وصلة. نظرًا لأن Tendermint يمكنها تنفيذ الكتل بشكل أسرع بكثير من Ethereum proof-of-work، EVM المناطق المدعومة بإجماع Tendermint و يمكن أن يوفر التشغيل على الأثير الجسري أداءً أعلى Ethereum blockchains. بالإضافة إلى ذلك، على الرغم من أن Cosmos Hub و IBC لا تسمح آليات الحزم بمنطق العقد التعسفي التنفيذ في حد ذاته، يمكن استخدامه لتنسيق حركات token بين Ethereum العقود الجاري تنفيذها في مناطق مختلفة، توفير أساس للتوسع token المتمركز حول Ethereum عبر مشاركة. تعمل مناطق Cosmos على تشغيل منطق التطبيق التعسفي، والذي تم تحديده عند بداية حياة المنطقة ويمكن تحديثها مع مرور الوقت من قبل الحكم. تسمح هذه القابلية للمناطق بـ Cosmos بمثابة جسور إلى العملات المشفرة الأخرى مثل Ethereum أو Bitcoin، كما أنه يسمح بمشتقات تلك blockchains، باستخدام نفس قاعدة التعليمات البرمجية ولكن مع مجموعة validator مختلفة و التوزيع الأولي. وهذا يسمح للعديد من العملات المشفرة الموجودة أطر العمل، مثل تلك الخاصة بـ Ethereum، وZerocash، وBitcoin، CryptoNote وما إلى ذلك، لاستخدامها مع Tendermint Core، وهو محرك توافقي عالي الأداء، على شبكة مشتركة، فتح فرصة هائلة للتشغيل البيني عبر المنصات. علاوة على ذلك، باعتباره أصلًا متعددًا blockchain، واحدًا قد تحتوي المعاملة على مدخلات ومخرجات متعددة، حيث يكون كل منها يمكن أن يكون الإدخال من أي نوع token، مما يتيح لـ Cosmos العمل مباشرةً كـ منصة للتبادل اللامركزي، على الرغم من افتراض الأوامرلتتم مطابقتها عبر منصات أخرى. بدلا من ذلك، يمكن للمنطقة أن تخدم كتبادل موزع متسامح مع الأخطاء (مع دفاتر الطلبات)، والذي يمكن أن يكون هناك تحسن صارم على المركزية الموجودة بورصات العملات المشفرة التي تميل إلى الاختراق مع مرور الوقت. يمكن أن تعمل المناطق أيضًا كإصدارات مدعومة من المؤسسة blockchain والأنظمة الحكومية، حيث أجزاء من خدمة معينة تدار تقليديا من قبل منظمة أو مجموعة من المنظمات يتم تشغيلها بدلاً من ذلك كتطبيق ABCI في منطقة معينة، والتي يسمح لها بوراثة الأمن وقابلية التشغيل البيني للجمهور Cosmos الشبكة دون التضحية بالتحكم في الشبكة الأساسية الخدمة. وبالتالي، قد يقدم Cosmos أفضل ما في العالمين المنظمات التي تتطلع إلى الاستفادة من تقنية blockchain ولكن من هي؟ الحذر من التخلي عن السيطرة بالكامل للثلث الموزع حزب. يدعي البعض أن هناك مشكلة كبيرة في تفضيل الاتساق خوارزميات الإجماع مثل Tendermint هي أن أي شبكة القسم الذي يتسبب في عدم وجود قسم واحد به >⅔ قوة التصويت (على سبيل المثال ≥⅓ الذهاب للخارج) ستوقف الإجماع تمامًا. يمكن أن تساعد بنية Cosmos في تخفيف هذه المشكلة باستخدام مركز عالمي مع مناطق الحكم الذاتي الإقليمية، حيث قوة التصويت لكل منطقة يتم توزيعها على أساس جغرافي مشترك المنطقة. على سبيل المثال، قد يكون النموذج المشترك للفرد المدن أو المناطق لتشغيل مناطقها الخاصة أثناء مشاركة أ المركز المشترك (على سبيل المثال، المركز Cosmos)، مما يتيح للنشاط البلدي تستمر في حالة توقف المحور بسبب شبكة مؤقتة التقسيم. لاحظ أن هذا يسمح بالجيولوجية والسياسية الحقيقية الميزات الطوبولوجية للشبكة التي يجب مراعاتها عند التصميم القوي الأنظمة الموحدة المتسامحة مع الأخطاء.
كانت NameCoin واحدة من أوائل blockchains التي حاولت حل مشكلة مشكلة تحليل الاسم عن طريق تكييف Bitcoin blockchain. لسوء الحظ كانت هناك العديد من المشاكل مع هذا النهج. باستخدام Namecoin، يمكننا التحقق من أن @satoshi، على سبيل المثال، كان كذلك مسجلة بمفتاح عام معين في وقت ما في الماضي، لكننا لا نعرف ما إذا كان المفتاح العام موجودًا منذ ذلك الحين تم تحديثه مؤخرًا ما لم نقم بتنزيل جميع الكتل منذ آخر مرة تحديث لهذا الاسم. ويرجع ذلك إلى القيود المفروضة على Bitcoin UTXO نموذج تحويل المعاملة Merkle، حيث فقط المعاملات (ولكن ليست حالة التطبيق القابلة للتغيير) هي من نوع Merkle في الكتلة-hash. وهذا يتيح لنا إثبات الوجود، ولكن ليس عدم وجود تحديثات لاحقة للاسم. وبالتالي، لا يمكننا أن نعرف تأكد من أحدث قيمة للاسم دون الثقة الكاملة العقدة، أو تكبد تكاليف كبيرة في النطاق الترددي عن طريق التنزيل كله blockchain. حتى لو تم تنفيذ شجرة بحث بحجم Merkle في NameCoin، اعتماده على proof-of-work يجعل عملية التحقق من العميل سهلة إشكالية. يجب على عملاء Light تنزيل نسخة كاملة من رؤوس جميع الكتل في blockchain بالكامل (أو على الأقل كل الرؤوس منذ آخر تحديث للاسم). وهذا يعني أن تتغير متطلبات عرض النطاق الترددي بشكل خطي مع مقدار الوقت [21]. بالإضافة إلى ذلك، يتغير الاسم على proof-of-work blockchain يتطلب انتظار كتل تأكيد إضافية proof-of-work، والذي يمكن أن يستغرق ما يصل إلى ساعة على Bitcoin. مع Tendermint، كل ما نحتاجه هو أحدث كتلة-hash موقعة من قبل نصاب قانوني قدره validators (بواسطة قوة التصويت)، وميركل دليل على القيمة الحالية المرتبطة بالاسم. هذا يجعلها من الممكن أن يكون لديك عميل خفيف مقتضب وسريع وآمن التحقق من قيم الاسم. في Cosmos، يمكننا أن نأخذ هذا المفهوم ونوسعه إلى أبعد من ذلك. كل يمكن أن تحتوي منطقة تسجيل الاسم في Cosmos على اسم نطاق المستوى الأعلى (TLD) مرتبط مثل ".com" أو ".org"، وكل اسم-
منطقة التسجيل يمكن أن يكون لها الإدارة والتسجيل الخاصة بها القواعد.
거버넌스와 경제
Cosmos 허브는 다중 자산 분산 원장이지만 다음이 있습니다. 원자라고 불리는 특별한 기본 token. 원자는 유일한 staking Cosmos 허브의 token. 아톰은 보유자가 다음을 수행할 수 있는 라이선스입니다. 다른 validator에 투표하고, 검증하고, 위임하세요. Ethereum처럼 에테르, 아톰은 거래 수수료를 지불하는 데에도 사용될 수 있습니다. 스팸을 완화하세요. 추가적인 Inzationary Atom 및 블록 트랜잭션 수수료는 validators 및 위임한 위임자에게 보상됩니다. validators. BurnAtomTx 거래는 모든 것을 복구하는 데 사용될 수 있습니다. 예비 풀에서 비례적인 양의 tokens. 창세기에서 원자 tokens 및 validators의 초기 분포 Cosmos 모금 행사의 기부자(75%), 주요 기부자에게 전달됩니다. (5%), Cosmos Network Foundation (10%) 및 ALL IN BITS, Inc (10%). 창세기부터 전체 원자량의 1/3이 매년 결속된 validator 및 위임자에게 보상을 받습니다. 자세한 내용은 Cosmos 계획을 참조하세요. Bitcoin 또는 다른 proof-of-work blockchain과 달리 Tendermint는 blockchain은 증가된 validator로 인해 속도가 느려집니다. 통신 복잡성. 다행히도 우리는 충분히 지원할 수 있습니다 validators는 전 세계적으로 분산된 강력한 blockchain을 만들기 위한 것입니다. 매우 빠른 트랜잭션 확인 시간과 대역폭으로서
스토리지와 병렬 컴퓨팅 용량이 늘어나면 다음과 같은 일이 가능해질 것입니다. 앞으로 더 많은 validator을 지원합니다. 생성일에는 최대 validator 수가 다음으로 설정됩니다. 100이고, 이 숫자는 10년 동안 13%의 비율로 증가할 것입니다. 300 validators에 정착합니다. 아직 Atom 보유자가 아닌 경우 다음을 통해 validator이 될 수 있습니다. BondTx 거래에 서명하고 제출합니다. 금액 담보로 제공되는 원자는 0이 아니어야 합니다. 누구나 될 수 있다 a validator, 현재 크기가 validator 세트가 최대 validator 수보다 큽니다. 허용됩니다. 이 경우 해당 거래는 해당 금액만큼만 유효합니다. 원자가 보유하고 있는 유효 원자의 양보다 크다. 가장 작은 validator, 여기서 유효 원자에는 위임된 원자가 포함됩니다. 이러한 방식으로 새로운 validator이 기존 validator을 대체하면, 기존 validator은 비활성화되고 모든 원자와 위임된 원자는 결합 해제 상태로 들어갑니다. 어떤 경우에도 validator에 약간의 벌금이 부과되어야 합니다. 의도적이거나 의도하지 않은 제재 조치로부터의 이탈 프로토콜. 일부 증거는 즉시 인정될 수 있습니다. 동일한 높이와 원형으로 이중 서명을 하거나 다음 사항을 위반하는 경우 0년차: 100 1년차: 113 2년차: 127 3년차: 144 4년차: 163 5년차: 184 6년차: 208 7년차: 235 8년차: 265 9년차: 300 10년차: 300 ...
"prevote-the-lock"(Tendermint 합의 프로토콜의 규칙). 이러한 증거로 인해 validator은(는) 좋은 평판을 잃게 됩니다. 그리고 그것의 결합된 원자뿐만 아니라 tokens의 비례적인 몫도 포함됩니다. 집합적으로 "스테이크"라고 불리는 예비 풀은 삭감됩니다. 때로는 지역적 문제로 인해 validator을 사용할 수 없는 경우도 있습니다. 네트워크 중단, 정전 또는 기타 이유. 만약, 혹시라도 과거 ValidatorTimeoutWindow 블록, validator의 시점을 가리킵니다. 커밋 투표는 blockchain에 포함되지 않습니다. ValidatorTimeoutMaxAbsent 회, 해당 validator는 다음과 같습니다. 비활성화되고 ValidatorTimeoutPenalty(기본값 1%)가 손실됩니다. 스테이크. 일부 "악의적인" 행동은 명확하게 식별할 수 없는 결과를 낳습니다. blockchain에 대한 증거. 이러한 경우 validator은 다음을 수행할 수 있습니다. 대역 외 조정을 통해 이러한 악성 코드의 시간 초과를 강제합니다. validators, 압도적인 합의가 있는 경우. ≥⅓ 연합으로 인해 Cosmos 허브가 중단되는 상황에서 투표권이 사라지거나 ≥⅓ 연합이 있는 상황에서 투표권 검열을 통해 악의적인 행위에 대한 증거를 검열합니다. blockchain를 입력하면 허브는 하드포크로 복구되어야 합니다. 재구성 제안. (“포크 및 검열 공격” 링크) Cosmos 허브 validators는 모든 token 유형 또는 조합을 허용할 수 있습니다. 거래 처리에 대한 수수료 유형입니다. 각 validator은(는) 원하는 환율을 주관적으로 설정하고 선택하세요. BlockGasLimit가 다음인 한 원하는 거래는 무엇이든 가능합니다. 초과하지 않았습니다. 아래에 명시된 세금을 제외한 징수된 수수료는 담보된 이해관계자들에게 비율에 따라 재분배됩니다. ValidatorPayoutPeriod마다 결합된 원자(기본값 1 시간).징수된 거래 수수료 중 ReserveTax(기본 2%)는 예비 풀 쪽으로 가서 예비 풀을 늘리고 Cosmos 네트워크의 보안과 가치를 높입니다. 이것들 결정에 따라 자금을 분배할 수도 있습니다. 거버넌스 시스템에 의해 만들어졌습니다. 자신의 투표권을 다른 validator에게 위임하는 Atom 보유자 위임받은 validator에게 수수료를 지불하세요. 위원회는 다음을 수행할 수 있습니다. validator마다 설정됩니다. Cosmos 허브의 보안은 허브의 보안 기능입니다. 기본 validator 및 위임자의 위임 선택. 발견된 물질의 발견과 조기 보고를 장려하기 위해 취약점, Cosmos 허브는 해커가 게시하도록 권장합니다. 다음과 같은 ReportHackTx 트랜잭션을 통한 성공적인 악용 validator이 해킹당했습니다. 이 주소로 포상금을 보내주세요.” 시 이러한 악용으로 인해 validator 및 위임자는 비활성화됩니다. 모든 사람의 아톰의 HackPunishmentRatio(기본값 5%)는 슬래시 및 모든 원자의 HackRewardRatio(기본값 5%) 해커의 바운티 주소로 보상을 받게 됩니다. validator 백업 키를 사용하여 나머지 Atom을 복구해야 합니다. 이 기능이 남용되어 전송되는 것을 방지하기 위해 미확정 원자, 미확정 원자와 미확정 원자의 부분 ReportHackTx 전후의 validator 및 위임자는 동일하게 유지되며 해커 현상금에는 일부가 포함됩니다. 미확정 원자(있는 경우). Cosmos 허브는 분산 조직에 의해 운영됩니다. 이를 위해서는 잘 정의된 거버넌스 메커니즘이 필요합니다. 변수와 같은 blockchain에 대한 다양한 변경 사항을 조정합니다.
시스템의 매개 변수뿐만 아니라 소프트웨어 업그레이드 및 헌법 개정. 모든 validator은 모든 제안에 대한 투표를 담당합니다. 실패 적시에 제안에 투표하면 validator 결과가 발생합니다. 일정 시간 동안 자동으로 비활성화됩니다. 결석 처벌 기간(기본값 1주). 위임자는 위임자의 투표를 자동으로 상속받습니다. validator. 이 투표는 수동으로 무시될 수 있습니다. 결합되지 않은 원자 투표하지 마세요. 각 제안서에는 MinimumProposalDeposit의 보증금이 필요합니다. tokens(하나 이상의 tokens 조합일 수 있음) 원자를 포함하여. 각 제안에 대해 유권자는 투표를 통해 다음을 선택할 수 있습니다. 보증금. 유권자의 과반수 이상이 투표를 선택하는 경우 예치금(예: 제안이 스팸이었기 때문에), 예치금은 연소된 원자를 제외한 예비 풀. 각 제안에 대해 유권자는 다음 옵션을 선택하여 투표할 수 있습니다. 응 그래위드포스 아니 아니위드포스 기권 찬성 또는 YeaWithForce 투표의 절대 다수(또는 반대 또는 NayWithForce 투표)는 제안이 다음과 같이 결정되는 데 필요합니다. 통과(또는 실패로 결정)되었지만 1/3 이상이 다수를 거부할 수 있음 "강력하게" 투표하여 결정합니다. 절대 다수가 거부권을 행사하면, 모든 사람은 VetoPenaltyFeeBlocks를 잃음으로써 처벌을 받습니다. (기본 1일 블록) 상당의 수수료(세금 제외) 영향을 받지 않음) 및 대다수를 거부한 당사자
결정은 VetoPenaltyAtoms 상실로 추가 처벌을 받게 됩니다. (기본값 0.1%) 원자의 수입니다. 여기에 정의된 모든 매개변수는 다음을 사용하여 변경할 수 있습니다. ParameterChangeProposal 을 전달합니다. 원자는 인젝션될 수 있으며 풀 자금을 다음과 같이 사용할 수 있습니다. BountyProposal 전달. 프로토콜 업그레이드 제안 등 기타 모든 제안은 일반 TextProposal을 통해 조정됩니다. 계획을 참조하십시오. blockchain 합의에는 많은 혁신이 있었고 지난 몇 년간의 확장성. 이 섹션에서는 간략한 설명을 제공합니다. 중요한 항목을 선정하여 조사합니다. 악의적 참여자 존재에 대한 합의가 문제 Leslie Lamport가 이 용어를 만들었던 1980년대 초로 거슬러 올라갑니다. "비잔틴 결함"이라는 문구는 임의의 프로세스 동작을 나타냅니다. "충돌 결함"과 달리 의도된 동작에서 벗어납니다. 여기서 프로세스는 단순히 충돌합니다. 초기 솔루션이 발견되었습니다. 상한이 있는 동기 네트워크의 경우실제 사용은 매우 제한되었지만 메시지 대기 시간 비행기 컨트롤러와 같은 통제된 환경 원자 시계를 통해 동기화되는 데이터 센터. 그때까지는 아니었지만 Practical Byzantine Fault Tolerance(PBFT) [11]이 있었던 90년대 후반 효율적인 부분 동기식 합의로 도입되었습니다. 최대 1/3의 프로세스 동작을 허용할 수 있는 알고리즘 임의로. PBFT은 표준 알고리즘이 되어 많은 알고리즘을 생성했습니다. 가장 최근에 IBM이 다음의 일부로 만든 변형을 포함한 변형 Hyperledger에 대한 기여. PBFT에 대한 Tendermint 합의의 주요 이점은 다음과 같습니다. Tendermint는 개선되고 단순화된 기본 구조를 가지고 있습니다. 그 중 일부는 blockchain 패러다임을 수용한 결과입니다. Tendermint 블록은 순서대로 커밋해야 합니다. PBFT과 관련된 복잡성 및 통신 오버헤드 보기 변경. Cosmos 및 많은 암호화폐에는 블록 N이 커밋될 때 i >= 1인 블록 N+i를 허용해야 합니다. 자체는 아직 커밋되지 않았습니다. 대역폭이 N을 차단하는 이유라면 Cosmos 영역에 커밋하지 않았다면 사용하는 데 도움이 되지 않습니다. N+i 블록에 대한 대역폭 공유 투표. 네트워크 파티션 또는 ofzine 노드는 블록 N이 커밋되지 않은 이유입니다. N+i는 어쨌든 커밋하지 않습니다. 또한 트랜잭션을 블록으로 일괄 처리하면 다음과 같은 이점이 있습니다. 대신 애플리케이션 상태의 일반 Merkle-hashing PBFT의 체크포인트 체계와 마찬가지로 주기적 다이제스트. 이를 통해 라이트 클라이언트를 위한 보다 빠른 증명 가능한 트랜잭션 커밋을 위해 inter-blockchain 통신. Tendermint Core에는 다양한 최적화 및 기능도 포함되어 있습니다. PBFT에 명시된 것 이상입니다. 예를 들어, validators가 제안한 블록은 Merkle화되어 여러 부분으로 분할됩니다. 방송을 개선하는 방식으로 험담을 했습니다. 성능(영감을 얻으려면 LibSwift [19] 참조). 또한 텐더민트는 Core는 Point-to-Point에 대해 어떠한 가정도 하지 않습니다.
P2P 네트워크가 있는 한 연결 및 기능은 약하게 연결되어 있습니다. proof-of-stake(PoS)을 배포한 최초는 아니지만 BitShares1.0 [12] PoS 연구 및 채택에 크게 기여 blockchain, 특히 "위임된" PoS로 알려진 것입니다. 에서 BitShares, 지분 보유자는 주문을 담당하는 "증인"을 선출합니다. 거래를 커밋하고 "대리인"이 책임을 집니다. 소프트웨어 업데이트 및 매개변수 변경 조정. BitShares2.0은 고성능(100k tx/s, 1s) 달성을 목표로 합니다. 대기 시간) 이상적인 조건에서 각 블록은 단일 서명으로 서명됩니다. 서명자 및 트랜잭션 연속성은 서명자보다 꽤 오래 걸립니다. 블록 간격. 정식 사양은 아직 개발 중입니다. 이해관계자는 잘못된 행동을 하는 증인을 제거하거나 교체할 수 있습니다. 매일매일, 그러나 증인이나 중요한 담보가 없습니다. Tendermint PoS와 유사한 위임자가 삭제됩니다. 이중지불 공격이 성공한 경우. Ripple이 개척한 접근 방식을 기반으로 Stellar [13]은 프로세스가 진행되는 Federated Byzantine Agreement 모델 합의에 참여하는 것은 yxed 및 전 세계적으로 구성되지 않습니다. 알려진 세트. 오히려 각 프로세스 노드는 하나 이상의 "쿼럼 슬라이스"는 각각 신뢰할 수 있는 프로세스 집합을 구성합니다. 에이 Stellar의 "쿼럼"은 다음을 포함하는 노드 집합으로 정의되었습니다. 집합의 각 노드에 대해 최소 하나의 쿼럼 슬라이스 합의가 이루어질 수 있습니다. Stellar 메커니즘의 보안은 다음 가정에 의존합니다. 두 정원회의 교차점은 비어 있지 않은 반면, 노드를 사용하려면 최소한 하나의 쿼럼 슬라이스가 필요합니다. 완전히 올바른 노드로 구성되어 균형을 맞추기 어려울 수 있는 크거나 작은 쿼럼 슬라이스 사용 신뢰에 대해 중요한 가정을 부과하지 않고. 궁극적으로,노드는 어떻게든 적절한 쿼럼 슬라이스를 선택해야 합니다. 충분한 내결함성(또는 "온전한 노드")이 있어야 합니다. 논문 결과의 대부분은)에 달려 있으며, 유일한 이러한 구성이 계층적으로 이루어지도록 하기 위한 전략 제공 인터넷의 최상위 ISP가 글로벌 라우팅 테이블을 구축하는 데 사용하는 BGP(Border Gateway Protocol)와 유사합니다. TLS 인증서를 관리하기 위해 브라우저에서 사용하는 것입니다. 둘 다 악명 높은 그들의 불안 때문에. Tendermint 기반 지분 증명 시스템에 대한 Stellar 논문의 비판은 설명된 token 전략에 의해 완화됩니다. 여기에서 원자라고 불리는 새로운 유형의 token이 발행됩니다. 수수료 및 보상의 미래 부분에 대한 청구를 나타냅니다. 는 그렇다면 Tendermint 기반 proof-of-stake의 장점은 상대적입니다. 단순하면서도 충분하고 입증 가능한 보안을 제공합니다. 보증. BitcoinNG는 Bitcoin에 대해 제안된 개선 사항입니다. 블록 크기 증가와 같은 수직 확장성의 형태에 대해 일반적으로 관련된 부정적인 경제적 결과 없이 불균형적으로 큰 영향과 같은 변화로 인해 소규모 광부에서. 이러한 개선은 분리를 통해 달성됩니다. 거래 방송에서 리더 선출: 리더가 첫 번째입니다. "마이크로 블록"에서 proof-of-work에 의해 선출되었으며 다음을 수행할 수 있습니다. 새로운 마이크로 블록이 나올 때까지 커밋되는 브로드캐스트 트랜잭션 발견되었습니다. 이렇게 하면 필요한 대역폭 요구 사항이 줄어듭니다. PoW 경주에서 승리하여 소규모 채굴자들이 더욱 공정하게 경쟁할 수 있도록 하고, 그리고 트랜잭션이 보다 정기적으로 커밋되도록 허용합니다. 마이크로 블록을 발견하는 마지막 광부. 캐스퍼 [16]는 제안된 proof-of-stake 합의 알고리즘입니다. Ethereum. 주요 작동 모드는 "베팅별 합의"입니다. 작성자: validators가 자신이 믿는 블록에 반복적으로 베팅하도록 합니다.
다른 베팅을 바탕으로 blockchain에 전념하게 됩니다. 지금까지 보아온 것처럼 결국에는 동질성이 달성될 수 있습니다. 링크. 이는 Casper 팀이 활발히 연구하고 있는 분야입니다. 는 도전 과제는 다음과 같은 베팅 메커니즘을 구축하는 것입니다. 진화적으로 안정적인 전략임이 입증되었습니다. 주요 혜택 Tendermint와 비교하여 Casper는 "가용성"을 제공할 수 있습니다. 과도한 일관성” – 합의에는 >⅔ 정족수가 필요하지 않습니다. 투표권 – 아마도 커밋 속도를 희생하거나 구현 복잡성. Interledger 프로토콜 [14]은 엄밀히 말하면 확장성 솔루션이 아닙니다. 그것 서로 다른 원장 간의 임시 상호 운용성을 제공합니다. 느슨하게 결합된 양자 관계 네트워크를 통해 시스템을 구축합니다. 라이트닝 네트워크와 마찬가지로 ILP의 목적은 다음과 같습니다. 하지만 특히 서로 다른 결제에 초점을 맞추고 있습니다. 원장 유형을 지정하고 원자 트랜잭션 메커니즘을 다음으로 확장합니다. hash-잠금뿐만 아니라 공증인 정족수(라고 함)도 포함합니다. 원자 전송 프로토콜). 후자의 메커니즘은 원장 간 거래에서 원자성을 적용하는 것은 다음과 유사합니다. Tendermint의 라이트 클라이언트 SPV 메커니즘 ILP와 Cosmos/IBC 간의 구별이 보장됩니다. 아래에 제공됩니다. 1. ILP 커넥터의 공증인은 멤버십을 지원하지 않습니다. 변경하고 사이에 zexible 가중치를 허용하지 않습니다. 공증인. 반면에 IBC은(는) 특별히 다음을 위해 설계되었습니다. blockchains(여기서 validators는 서로 다른 가중치를 가질 수 있음) 회원 자격은 기간 중에 변경될 수 있습니다. blockchain. 2. 라이트닝 네트워크와 마찬가지로 ILP의 결제 수신자는 보낸 사람에게 확인 메시지를 다시 보내려면 온라인 상태여야 합니다. 에서token은 수신기의 validator 세트인 IBC을 통해 전송됩니다. blockchain은(는) 확인 제공을 담당합니다. 받는 사용자. 3. 가장 눈에 띄는 차이점은 ILP의 커넥터가 그렇지 않다는 것입니다. 지불에 대해 책임을 지거나 권위 있는 상태를 유지하는 것, Cosmos에서는 허브의 validator이 다음의 권한입니다. IBC token의 상태 및 이전 권한 각 구역이 보유한 token의 양(그러나 tokens는 영역 내의 각 계정이 보유합니다). 이것은 안전한 비대칭을 가능하게 하는 근본적인 혁신 token을 영역에서 영역으로 전송합니다. ILP와 유사 Cosmos의 커넥터는 지속적이고 최대한 안전합니다. blockchain 원장, Cosmos 허브. 4. ILP의 원장 간 지불은 다음의 지원을 받아야 합니다. 교환 주문서는 비대칭 전송이 없기 때문에 하나의 원장에서 다른 원장으로의 동전, 가치 이전 또는 시장 등가물. 사이드체인 [15]은 Bitcoin 확장을 위해 제안된 메커니즘입니다. "양방향 고정"된 대체 blockchain을 통한 네트워크 Bitcoin blockchain. (양방향 페깅은 다음과 같습니다. 브리징. Cosmos에서는 마켓페깅과 구별하기 위해 "브리징"이라고 말합니다. 사이드체인을 사용하면 비트코인이 사이드체인에서 효과적으로 이동할 수 있습니다. Bitcoin blockchain을 사이드체인과 후면에 연결하고 다음을 허용합니다. 사이드체인의 새로운 기능을 실험합니다. 에서와 같이 Cosmos 허브, 사이드체인 및 Bitcoin은 라이트 클라이언트 역할을 합니다. SPV 증명을 사용하여 코인이 언제 발행되어야 하는지 결정합니다. 사이드체인으로 옮겨졌다가 다시 돌아왔습니다. 물론, Bitcoin 이후로 proof-of-work을 사용하고, Bitcoin을 중심으로 한 사이드체인이 어려움을 겪습니다. proof-of-work의 많은 문제와 위험으로부터 합의 메커니즘. 게다가 이것은 Bitcoin-극대주의자입니다. 다양한 token을 기본적으로 지원하지 않는 솔루션 및
Cosmos과 같은 영역 간 네트워크 토폴로지입니다. 즉 핵심은 양방향 페그의 메커니즘은 원칙적으로 다음과 동일합니다. Cosmos 네트워크에 고용되어 있습니다. Ethereum은 현재 다양한 전략을 연구하고 있습니다. Ethereum blockchain의 상태를 샤딩하여 주소를 지정합니다. 확장성이 필요합니다. 이러한 노력은 현재 Ethereum 가상 머신이 제공하는 추상화 계층 공유 상태 공간 전반에 걸쳐. 다양한 연구 노력은 현재 진행 중입니다. [18][22] Cosmos 및 Ethereum 2.0 Mauve [22]은 디자인 목표가 다릅니다. Cosmos은(는) 특히 token에 관한 것입니다. Mauve는 스케일링에 관한 것입니다. 일반 계산. Cosmos은 EVM에 바인딩되지 않으므로 다른 VM도 가능합니다. 상호 운용. Cosmos을 통해 영역 작성자가 누가 검증하는지 결정할 수 있습니다. 구역. 누구나 Cosmos에서 새 영역을 시작할 수 있습니다(거버넌스가 아닌 경우). 달리 결정합니다). 허브는 영역 오류를 격리하므로 전역 token 불변성은 보존. 라이트닝 네트워크는 제안된 token 전송 네트워크입니다. Bitcoin blockchain(및 기타 공개) 위의 레이어에서 작동 blockchains), 수십 배의 개선이 가능합니다. 대부분의 트랜잭션을 이동하여 트랜잭션 처리량 향상 합의 원장 외부에서 소위 "결제 채널"로 전환됩니다.이는 온체인 암호화폐 스크립트를 통해 가능해졌습니다. 당사자들이 양자 간 국가 계약을 체결할 수 있도록 합니다. 디지털 서명 및 계약을 공유하여 상태를 업데이트할 수 있습니다. blockchain에 증거를 최종적으로 게시하여 종료할 수 있습니다. 메커니즘은 크로스체인 원자 교환을 통해 처음으로 대중화되었습니다. 작성자: 많은 당사자들과 결제 채널을 개설하고, 라이트닝 네트워크는 라우팅의 중심이 될 수 있습니다. 완전히 연결된 결제 채널로 이어지는 타인의 결제 지불 채널에 자본이 묶여 있는 대가를 치르게 됩니다. 라이트닝 네트워크는 여러 곳으로 쉽게 확장될 수도 있습니다. 가치 이전을 허용하는 여러 개의 독립적인 blockchain 교환시장을 통해서는 비대칭적으로 사용될 수 없습니다. token을 하나의 blockchain에서 다른 blockchain로 전송합니다. 메인 베니트 여기에 설명된 Cosmos 네트워크의 기능은 이러한 직접적 사용을 가능하게 하는 것입니다. token 전송. 즉, 우리는 지불 채널과 라이트닝 네트워크는 우리와 함께 널리 채택될 것입니다. token 비용 절감 및 개인 정보 보호를 위한 전송 메커니즘. 분리된 증인은 Bitcoin 개선 제안 링크입니다. 블록당 트랜잭션 처리량을 2배 또는 3배 증가시키는 것을 목표로 합니다. 동시에 새로운 노드에 대한 블록 동기화를 더 빠르게 만듭니다. 이 솔루션의 뛰어난 점은 다음과 같은 환경 내에서 작동하는 방식에 있습니다. Bitcoin의 현재 프로토콜 제한 사항 및 소프트 포크 허용 업그레이드(예: 이전 버전의 소프트웨어를 사용하는 클라이언트는 업그레이드 후에도 계속 작동합니다). 텐더민트, 새로운 존재가 되다 프로토콜에는 설계 제한이 없으므로 크기 조정이 다릅니다. 우선순위. 기본적으로 Tendermint는 BFT 라운드 로빈 알고리즘을 사용합니다. 채굴 대신 암호화 서명을 기반으로 하는 여러 병렬을 통해 수평 확장을 간단하게 허용합니다. blockchains, 정기적이고 더 빈번한 블록 커밋은 다음을 허용합니다. 수직 스케일링도 가능합니다.
الحكم والاقتصاد
في حين أن Cosmos Hub عبارة عن دفتر أستاذ موزع متعدد الأصول، إلا أنه يوجد أصل خاص token يسمى الذرة. الذرات هي staking الوحيدة token للمركز Cosmos. الذرات هي رخصة لحاملها التصويت أو التحقق من الصحة أو التفويض إلى validators أخرى. مثل Ethereum الأثير، يمكن أيضًا استخدام الذرات لدفع رسوم المعاملات تخفيف البريد العشوائي. ذرات إنزاتيوناري إضافية ومعاملة كتلة تتم مكافأة الرسوم إلى validator والمفوضين الذين يفوضون ذلك validators. ويمكن استخدام معاملة BurnAtomTx لاسترداد أي منها مبلغ متناسب من tokens من المجمع الاحتياطي. التوزيع الأولي للذرة tokens و validators في سفر التكوين سيذهب إلى الجهات المانحة لجمع التبرعات Cosmos (75%)، الجهات المانحة الرئيسية (5%)، Cosmos مؤسسة الشبكة (10%)، وALL IN BITS, Inc (10%). ومن لحظة التكوين فصاعدًا، سوف يصبح ثلث إجمالي كمية الذرات سيتم مكافأتك للمستعبدين validator والمفوضين كل عام. راجع خطة Cosmos للحصول على تفاصيل إضافية. على عكس Bitcoin أو غيره من proof-of-work blockchains، فإن Tendermint blockchain يصبح أبطأ مع المزيد من validators بسبب الزيادة تعقيد الاتصالات. ولحسن الحظ، يمكننا دعم ما يكفي validators لإنشاء blockchain قوي وموزع عالميًا مع أوقات تأكيد المعاملات السريعة جدًا، وعرض النطاق الترددي،
التخزين، وزيادة سعة الحوسبة الموازية، سنكون قادرين لدعم المزيد من validators في المستقبل. في يوم التكوين، سيتم تعيين الحد الأقصى لعدد validators إلى 100، وسيزداد هذا العدد بمعدل 13% لمدة 10 سنوات، و استقر عند 300 validators. يمكن لحاملي الذرة الذين ليسوا بالفعل أن يصبحوا validators بحلول التوقيع على معاملة BondTx وإرسالها. كمية الذرات المقدمة كضمان يجب أن تكون غير صفرية. يمكن لأي شخص أن يصبح validator في أي وقت، إلا عندما يكون حجم التيار مجموعة validator أكبر من الحد الأقصى لعدد validators مسموح به. في هذه الحالة، تكون المعاملة صالحة فقط إذا كان المبلغ الذرات أكبر من كمية الذرات الفعالة التي يحتفظ بها الأصغر validator، حيث تشمل الذرات الفعالة الذرات المفوضة. عندما يحل validator الجديد محل validator الحالي بهذه الطريقة، validator الموجود يصبح غير نشط وجميع الذرات و تدخل الذرات المفوضة إلى حالة فك الارتباط. يجب أن يتم فرض بعض العقوبات على validators لأي منها الانحراف المقصود أو غير المقصود عن العقوبة البروتوكول. يتم قبول بعض الأدلة على الفور، مثل أ علامة مزدوجة على نفس الارتفاع والدائرية، أو انتهاكا السنة 0: 100 السنة الأولى: 113 السنة الثانية: 127 السنة 3: 144 السنة الرابعة: 163 السنة 5: 184 السنة 6: 208 السنة 7: 235 السنة 8: 265 السنة 9: 300 السنة 10: 300 ...
"prevote-the-lock" (قاعدة من بروتوكول إجماع Tendermint). سيؤدي مثل هذا الدليل إلى فقدان validator لوضعه الجيد وذراتها المرتبطة بالإضافة إلى حصتها التناسبية البالغة tokens في سيتم تخفيض مجموع الاحتياطي - الذي يطلق عليه مجتمعًا "حصته" -. في بعض الأحيان، لن يكون validators متاحًا، إما بسبب المنطقة انقطاع الشبكة أو انقطاع التيار الكهربائي أو لأسباب أخرى. إذا، في أي نقطة في كتل ValidatorTimeoutWindow السابقة، validator لم يتم تضمين التصويت الالتزام في blockchain أكثر من مرات ValidatorTimeoutMaxAbsent، سيصبح validator غير نشط، وتفقد ValidatorTimeoutPenalty (الافتراضي 1%) من قيمته حصة. بعض السلوكيات "الخبيثة" لا يمكن تمييزها بشكل واضح الأدلة على blockchain. في هذه الحالات، يمكن لـ validators التنسيق خارج النطاق لفرض انتهاء مهلة هذه البرامج الضارة validators، إذا كان هناك إجماع بأغلبية ساحقة. في المواقف التي يتوقف فيها Cosmos Hub بسبب تحالف ≥⅓ من تختفي قوة التصويت، أو في الحالات التي يكون فيها ائتلاف ≥⅓ دليل رقابي على قوة التصويت على السلوك الخبيث من عند إدخال blockchain، يجب أن يتعافى المحور باستخدام شوكة صلبة اقتراح إعادة التنظيم. (رابط إلى "هجمات الشوكات والرقابة"). Cosmos يمكن للمحور validators قبول أي نوع أو مجموعة token أنواعها كرسوم معالجة معاملة. كل validator يمكن قم بتعيين سعر الصرف الذي تريده بشكل شخصي، ثم اختر مهما كانت المعاملات التي تريدها، طالما أن BlockGasLimit هو كذلك لم يتم تجاوزها. الرسوم المحصلة، ناقص أي ضرائب محددة أدناه، يتم إعادة توزيعها على أصحاب المصلحة المستعبدين بما يتناسب مع ذراتها المرتبطة، كل ValidatorPayoutPeriod (الافتراضي 1 ساعة).من بين رسوم المعاملات المحصلة، سيتم تطبيق ReserveTax (الافتراضي 2%) اذهب نحو تجمع الاحتياطي لزيادة تجمع الاحتياطي و زيادة أمان وقيمة شبكة Cosmos. هذه ويمكن أيضًا توزيع الأموال وفقًا للقرارات صنعها نظام الحكم. أصحاب الذرة الذين يفوضون سلطة التصويت الخاصة بهم إلى validators آخرين دفع عمولة للمفوض validator. يمكن للجنة يتم تعيينها بواسطة كل validator. يعد أمان Cosmos Hub إحدى وظائف أمان validators واختيار التفويض من قبل المفوضين. من أجل تشجيع الاكتشاف والإبلاغ المبكر عما تم العثور عليه الثغرات الأمنية، يشجع مركز Cosmos المتسللين على النشر عمليات استغلال ناجحة عبر معاملة ReportHackTx التي تنص على أن "هذا تم اختراق validator. من فضلك أرسل المكافأة إلى هذا العنوان". على مثل هذا الاستغلال، سيصبح validator والمفوضون غير نشطين، HackPunishmentRatio (الافتراضي 5%) من ذرات الجميع سيحصلون عليها مقطوعة، و HackRewardRatio (افتراضي 5%) من ذرات الجميع سوف تحصل على مكافأة على عنوان مكافأة المتسلل. validator يجب استعادة الذرات المتبقية باستخدام مفتاح النسخ الاحتياطي الخاص بهم. من أجل منع إساءة استخدام هذه الميزة للنقل الذرات غير المكتسبة، جزء من الذرات المكتسبة مقابل الذرات غير المكتسبة validators والمفوضون قبل وبعد ReportHackTx سوف تظل كما هي، وستتضمن مكافأة الهاكر بعضًا منها الذرات غير المستثمرة، إن وجدت. يتم تشغيل مركز Cosmos بواسطة مؤسسة موزعة يتطلب آلية حوكمة جيدة التصميم من أجل تنسيق التغييرات المختلفة على blockchain، مثل المتغير
معلمات النظام، بالإضافة إلى ترقيات البرامج و التعديلات الدستورية. جميع validator مسؤولون عن التصويت على جميع المقترحات. الفشل في سيؤدي التصويت على الاقتراح في الوقت المناسب إلى validator يتم إلغاء التنشيط تلقائيًا لفترة من الوقت تسمى عقوبة الغياب (أسبوع واحد افتراضيًا). يرث المفوضون صوت المفوض تلقائيًا validator. قد يتم تجاوز هذا التصويت يدويًا. الذرات غير المرتبطة لا تحصل على أي تصويت. يتطلب كل اقتراح إيداع مبلغ MinimumProposalDeposit tokens، والتي قد تكون مزيجًا من واحد أو أكثر من tokens بما في ذلك الذرات. بالنسبة لكل اقتراح، يجوز للناخبين التصويت لاتخاذه الوديعة. إذا اختار أكثر من نصف الناخبين التصويت الإيداع (على سبيل المثال، لأن الاقتراح كان غير مرغوب فيه)، يذهب الإيداع إلى المجمع الاحتياطي، باستثناء أي ذرات يتم حرقها. لكل مقترح، يمكن للناخبين التصويت بالخيارات التالية: نعم نعم مع القوة كلا NayWithForce امتنع عن التصويت أغلبية صارمة من أصوات نعم أو YeaWithForce (أو لا أو أصوات NayWithForce) مطلوبة حتى يتم تحديد الاقتراح تم إقراره (أو تقرر فشله)، ولكن يمكن لـ 1/3+ استخدام حق النقض ضد الأغلبية القرار بالتصويت "بالقوة". عندما يتم نقض الأغلبية الصارمة، تتم معاقبة الجميع بخسارة VetoPenaltyFeeBlocks (قيمة افتراضية للكتل ليوم واحد) بقيمة الرسوم (باستثناء الضرائب والتي لن تتأثر)، والحزب الذي اعترض على الأغلبية
ستتم معاقبة القرار أيضًا بخسارة VetoPenaltyAtoms (الافتراضي 0.1%) من ذراته. يمكن تغيير أي من المعلمات المحددة هنا باستخدام تمرير ParameterChangeProposal. يمكن تجميد الذرات واحتجاز أموال المجمع التي يتم إنفاقها باستخدام تمرير اقتراح المكافأة. جميع المقترحات الأخرى، مثل اقتراح ترقية البروتوكول، سيتم تنسيقه عبر TextProposal العام. انظر الخطة. لقد كان هناك العديد من الابتكارات في إجماع blockchain و قابلية التوسع في العامين الماضيين. يقدم هذا القسم نبذة مختصرة مسح لعدد مختار من المهم. الإجماع في وجود مشاركين خبيثين يمثل مشكلة يعود تاريخها إلى أوائل الثمانينيات، عندما صاغ ليزلي لامبورت عبارة "خطأ بيزنطي" للإشارة إلى سلوك العملية التعسفية ينحرف عن السلوك المقصود، على عكس "خطأ التصادم"، حيث تتعطل العملية ببساطة. تم اكتشاف الحلول المبكرة للشبكات المتزامنة حيث يوجد حد أعلىزمن وصول الرسالة، على الرغم من أن الاستخدام العملي كان يقتصر على درجة عالية البيئات الخاضعة للرقابة مثل وحدات التحكم في الطائرات و مراكز البيانات متزامنة عبر الساعات الذرية. ولم يكن حتى أواخر التسعينيات أن التسامح مع الخطأ البيزنطي العملي (PBFT) [11] كان تم تقديمه كإجماع متزامن فعال جزئيًا خوارزمية قادرة على تحمل ما يصل إلى ثلث العمليات التي تتصرف تعسفا. أصبحت PBFT هي الخوارزمية القياسية، مما أدى إلى ظهور العديد منها الاختلافات، بما في ذلك أحدثها التي تم إنشاؤها بواسطة IBM كجزء من مساهمتهم في Hyperledger. الميزة الرئيسية لإجماع Tendermint على PBFT هي ذلك يحتوي Tendermint على بنية أساسية محسنة ومبسطة، بعضها نتيجة لتبني نموذج blockchain. يجب أن تلتزم كتل Tendermint بالترتيب، مما يتجنب التعقيد وحمل الاتصالات المرتبط بـ PBFT تغييرات العرض. في Cosmos والعديد من العملات المشفرة، لا يوجد بحاجة إلى السماح للكتلة N+i حيث i >= 1 بالالتزام، عند الكتلة N نفسها لم تلتزم بعد. إذا كان عرض النطاق الترددي هو السبب وراء حظر N لم يتم الالتزام به في منطقة Cosmos، فلا يساعد في الاستخدام أصوات مشاركة النطاق الترددي للكتل N+i. إذا كان قسم الشبكة أو عقد ofzine هي السبب وراء عدم التزام الكتلة N N + لن ألتزم على أي حال. بالإضافة إلى ذلك، فإن تجميع المعاملات في كتل يسمح بذلك Merkle-hashing العادي لحالة التطبيق، بدلاً من الملخصات الدورية كما هو الحال مع مخطط نقاط التفتيش PBFT. هذا يسمح من أجل تنفيذ معاملات أسرع يمكن إثباتها للعملاء الخفيفين وبشكل أسرع التواصل بين blockchain. يتضمن Tendermint Core أيضًا العديد من التحسينات والميزات التي تتجاوز ما هو محدد في PBFT. على سبيل المثال، يتم تقسيم الكتل المقترحة بواسطة validators إلى أجزاء، بحجم Merkle، والنميمة بطريقة تعمل على تحسين البث الأداء (راجع LibSwift [19] للإلهام). أيضا، تندرمينت لا يقدم Core أي افتراضات حول نقطة إلى نقطة
الاتصال والوظائف طالما أن شبكة P2P موجودة متصلة بشكل ضعيف. على الرغم من أنها ليست أول من نشر proof-of-stake (PoS)، إلا أن BitShares1.0 [12] ساهم بشكل كبير في البحث واعتماد إثبات الحصة (PoS). blockchains، وخاصة تلك المعروفة باسم نقاط البيع "المفوضة". في BitShares، أصحاب المصلحة ينتخبون "الشهود"، المسؤولين عن الطلب وارتكاب المعاملات و"المندوبين" المسؤولين عنها تنسيق تحديثات البرامج وتغييرات المعلمات. يهدف BitShares2.0 إلى تحقيق أداء عالي (100k tx/s, 1s الكمون) في ظروف مثالية، مع كل كتلة موقعة من قبل واحد المُوقع، وتستغرق عملية المعاملة وقتًا أطول قليلاً من الفاصل الزمني للكتلة. لا تزال المواصفات الأساسية قيد التطوير. يمكن لأصحاب المصلحة إزالة أو استبدال الشهود الذين يسيئون التصرف على بشكل يومي، ولكن لا يوجد ضمانات هامة من الشهود أو المندوبون على غرار Tendermint PoS الذين تم اقتطاعهم حالة نجاح هجوم الإنفاق المزدوج. بناءً على النهج الذي ابتكرته شركة Ripple، Stellar [13] رينيد أ نموذج للاتفاقية البيزنطية الموحدة حيث تتم العمليات المشاركة في الإجماع لا تشكل yxed وعالميا مجموعة معروفة. بدلاً من ذلك، تقوم كل عقدة عملية برعاية واحدة أو أكثر "شرائح النصاب"، يشكل كل منها مجموعة من العمليات الموثوقة. أ "النصاب القانوني" في Stellar مصمم ليكون مجموعة من العقد التي تحتوي على شريحة نصاب واحدة على الأقل لكل عقدة في المجموعة، بحيث يمكن التوصل إلى اتفاق. يعتمد أمان آلية Stellar على الافتراض أن تقاطع أي نصابين غير فارغ، في حين أن يتطلب توفر العقدة شريحة واحدة على الأقل من شرائح النصاب القانوني الخاصة بها تتكون بالكامل من العقد الصحيحة، مما يخلق مفاضلة بين استخدام شرائح النصاب الكبيرة أو الصغيرة التي قد يكون من الصعب تحقيق التوازن فيها دون فرض افتراضات هامة حول الثقة. أخيرًا،يجب أن تختار العقد بطريقة أو بأخرى شرائح النصاب القانوني المناسبة لذلك أن يكون كافيًا للتسامح مع الأخطاء (أو أي "عقد سليمة" على الإطلاق، منها الكثير من نتائج الورقة تعتمد على)، والوحيد الإستراتيجية المقدمة لضمان مثل هذا التكوين هي تسلسل هرمي وهو مشابه لبروتوكول بوابة الحدود (BGP)، الذي يستخدمه مزودو خدمة الإنترنت من الدرجة الأولى على الإنترنت لإنشاء جداول التوجيه العالمية، ومن خلال التي تستخدمها المتصفحات لإدارة شهادات TLS؛ كلاهما سيئ السمعة لانعدام الأمن لديهم. تم تخفيف الانتقادات الواردة في ورقة Stellar الخاصة بأنظمة إثبات الملكية القائمة على Tendermint من خلال استراتيجية token الموضحة هنا، حيث يتم إصدار نوع جديد من token يسمى الذرة تمثل المطالبات بالأجزاء المستقبلية من الرسوم والمكافآت. ال إن ميزة proof-of-stake المستندة إلى Tendermint هي قريبها البساطة، مع الاستمرار في توفير الأمان الكافي والقابل للإثبات الضمانات. BitcoinNG هو تحسين مقترح لـ Bitcoin من شأنه أن يسمح لأشكال قابلية التوسع الرأسي، مثل زيادة حجم الكتلة، دون العواقب الاقتصادية السلبية المرتبطة عادة مع مثل هذا التغيير، مثل التأثير الكبير بشكل غير متناسب على عمال المناجم الصغيرة. ويتحقق هذا التحسن عن طريق الانفصال انتخاب القائد من بث المعاملات: القادة هم الأولون تم انتخابه بواسطة proof-of-work في "الكتل الصغيرة"، ثم أصبح قادرًا على ذلك يجب الالتزام بمعاملات البث حتى يتم إنشاء كتلة صغيرة جديدة تم العثور عليه. وهذا يقلل من متطلبات عرض النطاق الترددي اللازمة ل الفوز بسباق إثبات العمل (PoW)، مما يسمح لصغار عمال المناجم بالمنافسة بشكل أكثر عدالة، والسماح بإجراء المعاملات بشكل أكثر انتظامًا بواسطة آخر عامل منجم يعثر على كتلة صغيرة. Casper [16] عبارة عن خوارزمية إجماع proof-of-stake مقترحة لـ Ethereum. أسلوب عملها الأساسي هو "الإجماع على الرهان". بواسطة السماح لـ validators بالمراهنة بشكل متكرر على الكتلة التي يعتقدون أنها ستفعل
تصبح ملتزمًا بـ blockchain بناءً على الرهانات الأخرى كما رأوه حتى الآن، يمكن تحقيق النزعة الجنسية في نهاية المطاف. وصلة. يعد هذا مجال بحث نشط بواسطة فريق Casper. ال التحدي يكمن في بناء آلية الرهان التي يمكن أن تكون ثبت أنها استراتيجية مستقرة تطوريا. الفائدة الرئيسية من قد يكون Casper مقارنةً بـ Tendermint في تقديم "التوافر". "على الاتساق" - لا يتطلب الإجماع أكثر من ⅔ النصاب القانوني قوة التصويت - ربما على حساب سرعة الالتزام أو تعقيد التنفيذ. لا يعد بروتوكول Interledger [14] حلاً قابلاً للتوسع بشكل صارم. ذلك يوفر التشغيل البيني المخصص بين دفاتر الأستاذ المختلفة الأنظمة من خلال شبكة علاقات ثنائية مترابطة بشكل فضفاض. مثل شبكة Lightning Network، فإن الغرض من ILP هو التسهيل المدفوعات، لكنه يركز بشكل خاص على المدفوعات عبر متباينة أنواع دفتر الأستاذ، وتمتد آلية المعاملات الذرية إلى لا تتضمن فقط hash-الأقفال، ولكن أيضًا النصاب القانوني لكتاب العدل (يسمى بروتوكول النقل الذري). الآلية الأخيرة ل إن فرض الذرية في المعاملات بين دفاتر الأستاذ يشبه آلية SPV العميلة الخفيفة الخاصة بـ Tendermint، مثال توضيحي لـ التمييز بين ILP و Cosmos/IBC أمر مضمون، و المنصوص عليها أدناه. 1. لا يدعم كتاب العدل للموصل في ILP العضوية التغييرات، ولا تسمح بالترجيح بين كتاب العدل. من ناحية أخرى، تم تصميم IBC خصيصًا لـ blockchains، حيث يمكن أن يكون لـ validators أوزان مختلفة، و حيث يمكن أن تتغير العضوية على مدار blockchain. 2. كما هو الحال في Lightning Network، متلقي الدفع في ILP يجب أن يكون متصلاً بالإنترنت لإرسال رسالة تأكيد إلى المرسل. في أtoken نقل عبر IBC، مجموعة validator لجهاز الاستقبال blockchain هو المسؤول عن توفير التأكيد، وليس استقبال المستخدم. 3. الفرق الأكثر لفتًا للانتباه هو أن موصلات ILP ليست كذلك مسؤولاً أو يحتفظ بحالة موثوقة بشأن المدفوعات، بينما في Cosmos، validators للمحور هي سلطة حالة IBC token عمليات النقل بالإضافة إلى سلطة كمية tokens التي تحتفظ بها كل منطقة (ولكن ليس مقدار tokens التي يحتفظ بها كل حساب داخل المنطقة). هذا هو الابتكار الأساسي الذي يسمح بأمان غير متماثل نقل tokens من منطقة إلى أخرى؛ التناظرية لـ ILP الموصل في Cosmos هو موصل ثابت وآمن إلى أقصى حد blockchain دفتر الأستاذ، مركز Cosmos. 4. يجب أن تكون المدفوعات بين دفاتر الأستاذ في ILP مدعومة بـ دفتر أوامر الصرف، حيث لا يوجد نقل غير متماثل لـ عملات معدنية من دفتر أستاذ إلى آخر، فقط نقل القيمة أو معادلات السوق. السلاسل الجانبية [15] هي آلية مقترحة لتوسيع نطاق Bitcoin الشبكة عبر blockchains البديلة "المرتبطة في اتجاهين". Bitcoin blockchain. (الربط في اتجاهين يعادل التجسير. في Cosmos نقول "جسر" للتمييز عن ربط السوق). تسمح السلاسل الجانبية لعملات البيتكوين بالانتقال بشكل فعال من Bitcoin blockchain إلى السلسلة الجانبية والظهر، والسماح بـ تجربة الميزات الجديدة على السلسلة الجانبية. كما في Cosmos Hub والسلسلة الجانبية وBitcoin بمثابة عملاء خفيفين لـ بعضها البعض، باستخدام أدلة SPV لتحديد متى يجب أن تكون العملات المعدنية نقل إلى Sidechain والعودة. بالطبع منذ Bitcoin الاستخدامات proof-of-work، تعاني السلاسل الجانبية المتمركزة حول Bitcoin من مشاكل ومخاطر proof-of-work العديدة كما أ آلية الإجماع. علاوة على ذلك، هذا هو الحد الأقصى Bitcoin الحل الذي لا يدعم أصلاً مجموعة متنوعة من tokens و
طوبولوجيا الشبكة بين المناطق كما يفعل Cosmos. وقيل: جوهر آلية الربط في الاتجاهين هي من حيث المبدأ نفس تلك الآلية يعمل لدى شبكة Cosmos. يقوم Ethereum حاليًا بالبحث في عدد من الاستراتيجيات المختلفة لتقسيم حالة Ethereum blockchain لمعالجة احتياجات قابلية التوسع. وتهدف هذه الجهود إلى الحفاظ على طبقة التجريد التي تقدمها الآلة الافتراضية Ethereum الحالية عبر مساحة الدولة المشتركة. الجهود البحثية المتعددة هي الجارية في هذا الوقت. [18][22] Cosmos وEthereum 2.0 بنفسجي [22] لهما أهداف تصميمية مختلفة. Cosmos يتعلق بشكل خاص بـ tokens. البنفسجي يدور حول القياس الحساب العام. Cosmos غير مرتبط بـ EVM، لذلك يمكن حتى للأجهزة الافتراضية المختلفة التفاعل. Cosmos يتيح لمنشئ المنطقة تحديد من يقوم بالتحقق من صحة المنطقة. يمكن لأي شخص أن يبدأ منطقة جديدة في Cosmos (ما لم تكن الإدارة يقرر خلاف ذلك). يقوم المحور بعزل حالات فشل المنطقة بحيث تكون الثوابت العالمية token كذلك محفوظ. الشبكة المسرّعة هي شبكة نقل مقترحة token تعمل في طبقة أعلى Bitcoin blockchain (وغيرها من الطبقات العامة blockchains)، مما يتيح تحسين العديد من أوامر الحجم في إنتاجية المعاملات عن طريق نقل غالبية المعاملات خارج دفتر الأستاذ الإجماعي إلى ما يسمى "قنوات الدفع".أصبح هذا ممكنًا بفضل البرامج النصية للعملات المشفرة الموجودة على السلسلة، والتي تمكين الأطراف من الدخول في عقود ثنائية الحالة حيث يمكن تحديث الحالة من خلال مشاركة التوقيعات الرقمية والعقود يمكن إغلاقه عن طريق نشر الأدلة بشكل صريح على blockchain، أ الآلية التي تم نشرها لأول مرة عن طريق المقايضة الذرية عبر السلسلة. بواسطة فتح قنوات الدفع مع العديد من الأطراف والمشاركين في يمكن أن تصبح الشبكة المسرّعة نقاطًا محورية لتوجيه الشبكة مدفوعات الآخرين، مما يؤدي إلى قناة دفع متصلة بالكامل الشبكة، على حساب رأس المال الذي يتم ربطه بقنوات الدفع. بينما يمكن للشبكة المسرّعة أيضًا أن تمتد بسهولة عبرها عدة blockchains مستقلة للسماح بنقل القيمة عبر سوق الصرف، لا يمكن استخدامه بشكل غير متماثل نقل tokens من blockchain إلى آخر. الفائدة الرئيسية الغرض من شبكة Cosmos الموصوفة هنا هو تمكين هذا التوجيه المباشر token التحويلات. ومع ذلك، فإننا نتوقع قنوات الدفع و سيتم اعتماد شبكة Lightning Network على نطاق واسع جنبًا إلى جنب مع شبكتنا token آلية النقل، لتوفير التكاليف ولأسباب تتعلق بالخصوصية. الشاهد المنفصل هو رابط مقترح تحسين Bitcoin يهدف إلى زيادة إنتاجية المعاملات لكل كتلة 2X أو 3X، مع جعل مزامنة الكتلة أسرع للعقد الجديدة في نفس الوقت. يكمن تألق هذا الحل في كيفية عمله داخل قيود بروتوكول Bitcoin الحالي وتسمح بالشوكة الناعمة الترقية (أي أن العملاء الذين لديهم إصدارات أقدم من البرنامج سوف يقومون بذلك الاستمرار في العمل بعد الترقية). تندرمينت، كونها جديدة البروتوكول ليس له قيود على التصميم، لذلك له مقياس مختلف الأولويات. في المقام الأول، يستخدم Tendermint خوارزمية BFT المستديرة على أساس التوقيعات التشفير بدلا من التعدين، والتي يسمح بشكل تافه بالتحجيم الأفقي من خلال التوازي المتعدد blockchains، بينما تسمح عمليات الحظر المنتظمة والمتكررة بذلك التحجيم العمودي كذلك.
합의 및 기술적 세부사항
잘 설계된 합의 프로토콜은 다음을 제공해야 합니다. 허용 한도를 초과하는 경우 보장 그리고 합의는 실패합니다. 이는 특히 경제적인 측면에서 필요합니다. 비잔틴 행위가 상당한 재정적 이익을 가져올 수 있는 시스템 보상. 그러한 보장 중 가장 중요한 것은 합의를 야기한 프로세스가 실패(즉, 프로토콜의 클라이언트가 다른 값을 허용하게 함 - 포크)에 대한 규정에 따라 식별 및 처벌될 수 있습니다. 프로토콜 또는 법률 시스템일 수도 있습니다. 법체계가 갖춰지면 신뢰할 수 없거나 호출 비용이 지나치게 높기 때문에 validator은(는) 참가하려면 보증금을 예치해야 하며, 악의적인 행위가 있을 경우 예치금이 취소되거나 삭감될 수 있습니다. [10]이(가) 감지되었습니다. 이는 분기가 정기적으로 발생하는 Bitcoin과 다릅니다. 네트워크 비동기성과 바인딩의 확률적 특성으로 인해 부분적인 hash 충돌. 많은 경우에 악의적인 포크는 비동기성으로 인해 포크와 구별할 수 없습니다. Bitcoin은(는) 암시적인 것 외에 포크 책임을 안정적으로 구현합니다. 고아 블록을 채굴하기 위해 채굴자가 지불하는 기회 비용. 투표 단계를 PreVote 및 PreCommit이라고 합니다. 투표는 다음을 위해 할 수 있습니다 특정 블록 또는 Nil에 대한 것입니다. 우리는 >⅔ PreVotes 모음을 호출합니다. 같은 라운드의 단일 블록에 대해 폴카, >⅔ 컬렉션 동일한 라운드의 단일 블록에 대한 PreCommit은 Commit입니다. >⅔인 경우 같은 라운드에서 Nil에 대한 PreCommit은 다음 라운드로 이동합니다. 라운드. 프로토콜의 엄격한 결정론은 약한 문제를 야기한다는 점에 유의하십시오. 결함이 있는 리더로서의 동시성 가정을 감지해야 하며
건너뛰었습니다. 따라서 validators는 일정 시간 동안 기다립니다. TimeoutPropose, Nil을 Prevote하기 전, 그리고 그 가치 TimeoutPropose는 라운드마다 증가합니다. 진행을 통해 라운드의 나머지 부분은 완전히 비동기식입니다. validator이 네트워크의 ⅔ 이상에서 수신되면 생성됩니다. 실제로, 이를 완전히 좌절시키려면 극도로 강력한 적이 필요할 것입니다. 약한 동시성 가정(합의 실패 원인) 블록을 커밋하는 경우) 그렇게 하면 훨씬 더 많은 일을 할 수 있습니다. 각각에 대해 TimeoutPropose의 무작위 값을 사용하여 difycult validator. 추가 제약 조건 세트 또는 잠금 규칙은 다음을 보장합니다. 네트워크는 결국 각 높이에서 단 하나의 블록만 커밋하게 됩니다. 모두 둘 이상의 블록이 커밋되도록 하는 악의적인 시도 특정 높이에서 식별할 수 있습니다. 먼저, 블록에 대한 PreCommit 해당 블록에 대해 폴카 형태로 정당성을 제시해야 합니다. validator가 R_1 라운드에서 이미 블록을 PreCommit한 경우 그 블록에 갇혀 있다고 말했고 폴카는 그 블록을 정당화하는 데 사용되었습니다. 라운드 R_2의 새로운 PreCommit은 라운드에 와야 합니다 R_polka 여기서 R_1 < R_polka <= R_2. 둘째, validators는 제안해야 합니다. 및/또는 잠겨 있는 블록에 사전 투표를 하세요. 함께, 이들 조건은 validator이 없이 PreCommit하지 않도록 보장합니다. 정당성을 입증하는 충분한 증거와 그 validator 이미 PreCommit은 PreCommit에 대한 증거에 기여할 수 없습니다. 다른 것. 이는 보안과 활성을 모두 보장합니다. 합의 알고리즘. 프로토콜의 전체 세부 사항은 여기에 설명되어 있습니다. 대체 체인(포크)이 존재한다는 것은 ≥⅓의 블록 헤더를 의미하므로 모든 블록 헤더를 동기화할 필요가 TendermintPoS에서는 제거됩니다. 담보 스테이크는 삭감될 수 있습니다. 물론 슬래싱이 필요하기 때문에 누군가가 포크의 증거를 공유한다는 사실을 라이트 클라이언트는 저장해야 합니다. 모든 블록-hash 커밋이 표시됩니다. 또한, 라이트 클라이언트validator 세트의 변경 사항과 주기적으로 동기화를 유지할 수 있습니다. 장거리 공격을 피하기 위해(그러나 다른 솔루션은 가능). Ethereum과 유사한 정신으로 Tendermint는 애플리케이션이 다음을 수행할 수 있도록 합니다. 각 블록에 전역 Merkle 루트 hash을 삽입하여 쉽게 허용 계정 잔액, 가치 등에 대한 검증 가능한 상태 쿼리 계약에 저장되어 있거나 사용되지 않은 거래의 존재 애플리케이션의 성격에 따라 출력됩니다. 충분히 탄력적인 방송 네트워크 모음을 가정합니다. 정적 validator 세트를 사용하면 blockchain의 모든 포크는 감지되어 문제가 되는 validators의 예금이 삭감되었습니다. 이 2014년 초 Vitalik Buterin이 처음으로 제안한 혁신은 다음과 같은 문제를 해결합니다. 다른 proof-of-stake의 위험 없는 문제 암호화폐(관련 작업 참조). 그러나 validator이 설정되었으므로 원본은 장기간에 걸쳐 변경될 수 있어야 합니다. validators는 모두 결합 해제될 수 있으므로 자유롭게 사용할 수 있습니다. 제네시스 블록에서 새로운 체인을 생성하며, 비용은 발생하지 않습니다. 더 이상 예금이 잠겨 있지 않습니다. 이 공격이 나왔습니다 단거리 공격과 달리 장거리 공격(LRA)으로 알려져 있음 현재 결속된 validators가 다음을 유발하는 범위 공격 포크로 인해 처벌을 받을 수 있습니다(포크 책임이 있는 BFT 가정). Tendermint 합의와 같은 알고리즘). 장거리 공격은 종종 proof-of-stake에 심각한 타격을 입혔다고 생각됩니다. 다행히 LRA는 다음과 같이 완화할 수 있다. 첫째, validator 채권을 해제하여 담보 예금을 회수합니다. 더 이상 합의에 참여하기 위해 수수료를 받지 않습니다.) 보증금은 일정 기간 동안 양도할 수 없도록 설정되어야 합니다. "결합 해제 기간"으로 알려져 있으며, 이는 다음과 같은 순서로 나타날 수 있습니다. 몇 주 또는 몇 달. 둘째, 라이트 클라이언트의 보안을 위해서는 가장 먼저 네트워크에 연결되면 최근 블록을 확인해야 합니다-hash 신뢰할 수 있는 소스 또는 바람직하게는 여러 소스에 대해. 이
상태는 때때로 "약한 주관성"으로 지칭됩니다. 마지막으로, 보안을 유지하려면 다음에 설정된 최신 validator과 동기화해야 합니다. 적어도 언본딩 기간만큼 자주. 이 라이트 클라이언트가 validator에 대한 변경 사항을 알고 있는지 확인합니다. validator 이전에 설정된 자본금은 채권이 해제되어 더 이상 존재하지 않습니다. 위태로워서 클라이언트를 속일 수 있습니다. 뒤에서 시작하는 새로운 블록을 생성하여 장거리 공격 접착된 높이(충분히 제어할 수 있다고 가정) 많은 초기 개인 키). 이러한 방식으로 LRA를 극복하려면 proof-of-work의 원래 보안 모델. PoW에서는 라이트 클라이언트가 현재 높이와 동기화할 수 있다고 가정합니다. 모든 블록 헤더의 작업 증명을 처리하기만 하면 언제든지 신뢰할 수 있는 제네시스 블록을 생성할 수 있습니다. 그러나 LRA를 극복하기 위해 우리는 라이트 클라이언트가 정기적으로 온라인에 접속하도록 요구합니다. validator 세트의 변경 사항을 추적하고, 처음으로 온라인에 접속하면 인증에 특히 주의해야 합니다. 신뢰할 수 있는 소스에 대해 네트워크에서 듣는 내용입니다. 의 물론 이 후자의 요구 사항은 Bitcoin의 요구 사항과 유사합니다. 프로토콜과 소프트웨어도 신뢰할 수 있는 곳에서 받아야 합니다. 소스. 위의 LRA 방지 방법은 validators에 매우 적합합니다. 그리고 Tendermint 기반 blockchain의 전체 노드는 다음과 같습니다. 노드는 네트워크에 연결된 상태를 유지하도록 되어 있습니다. 는 이 방법은 다음을 기대할 수 있는 라이트 클라이언트에도 적합합니다. 네트워크와 자주 동기화하세요. 그러나 라이트 클라이언트의 경우 인터넷이나 인터넷에 자주 접속할 것으로 예상되지 않습니다. blockchain 네트워크 문제를 극복하기 위해 또 다른 솔루션을 사용할 수 있습니다. LRA. validator token 보유자가 아닌 사람은 자신의 token을 다음과 같이 게시할 수 있습니다. 해제 기간이 매우 긴 담보(예: 훨씬 더 긴 기간) validators의 언본딩 기간보다) 라이트 클라이언트에게 서비스를 제공합니다. 현재의 타당성을 증명하는 두 번째 방법으로 지난 블록-hashes. 이 token은(는) 그럼에도 불구하고 blockchain 합의의 보안은 가능합니다.라이트 클라이언트에게 강력한 보증을 제공합니다. 과거 블록-hash인 경우 쿼리는 Ethereum에서 지원되었으며 누구나 자신의 특별히 고안된 smart contract의 tokens 및 제공 유료 증명 서비스를 제공하여 라이트 클라이언트 LRA 보안 시장을 효과적으로 창출합니다. 블록 커밋의 해제로 인해 ≥⅓ 연합은 투표 권한으로 진을 떠나거나 말거나 blockchain을 중단할 수 있습니다. 그들의 투표를 방송합니다. 그러한 연합은 검열도 할 수 있습니다. 이를 포함하는 블록을 거부하여 특정 거래 거래가 발생하더라도 상당한 비율의 거래가 발생하게 됩니다. 블록 제안이 거부되어 비율이 느려질 수 있습니다. blockchain의 블록 커밋이 줄어들어 유틸리티와 가치가 감소합니다. 악의적 연합은 투표를 조금씩 방송할 수도 있으므로 blockchain 블록을 갈아서 거의 정지하거나 이러한 공격의 조합. 마지막으로 다음과 같은 원인이 될 수 있습니다. blockchain 이중 서명 또는 잠금 위반으로 포크 규칙. 전 세계적으로 활동하는 적도 연루된 경우 분할될 수 있습니다. 잘못된 것처럼 보일 수 있는 방식으로 네트워크를 validator의 하위 집합이 속도 저하의 원인이었습니다. 이것은 아니다 Tendermint의 한계일 뿐 아니라 오히려 모든 것의 한계입니다. 네트워크가 잠재적으로 통제되는 합의 프로토콜 적극적인 적. 이러한 유형의 공격에 대해서는 validator의 하위 집합이 필요합니다. 외부 수단을 통해 조정하여 재구성 제안에 서명합니다. 포크(및 그 증거)와 초기 하위 집합을 선택합니다. validator의 서명이 포함되어 있습니다. 이러한 조직 개편 제안에 서명한 검증자는 다른 모든 포크에 대한 담보를 포기합니다. 클라이언트는 해야 합니다 재구성 제안의 서명을 확인하고, 증거를 확인하고, 판단을 내리거나 최종 사용자에게 결정을 촉구합니다. 에 대한 예를 들어 휴대폰 지갑 앱은 사용자에게 보안 메시지를 표시할 수 있습니다.
경고하는 반면 냉장고는 재구성 제안을 받아들일 수 있습니다. 투표권을 통해 원본 validator의 +½이 서명했습니다. 비동기식 비잔틴 결함 허용 알고리즘은 제공될 수 없습니다. 투표권의 ⅓ 이상이 부정직할 때 합의를 이루지만 포크는 투표권의 ⅓ 이상이 이미 부정직하다고 가정합니다. 정당화 없이 이중 서명 또는 잠금 변경. 그래서 서명을 재구성 제안은 조정할 수 없는 조정 문제입니다. 비동기 프로토콜로 해결됩니다(즉, 자동으로 신뢰성에 대한 가정을 하지 않고 기본 네트워크). 지금은 조직개편 조정 문제를 사회적 합의를 통한 인간의 조정에 맡겨둔다. 인터넷 매체에서. 검증인은 다음 사항을 보장하기 위해 주의를 기울여야 합니다. 두 개의 복잡한 재구성 제안이 서명되는 상황을 피하기 위해 재구성 제안에 서명하기 전에 남은 네트워크 파티션이 없습니다. 외부 조정 매체와 프로토콜이 다음과 같다고 가정합니다. 강력하기 때문에 포크는 검열보다 덜 문제가 됩니다. 공격. ≥⅓ 비잔틴이 필요한 포크 및 검열 외에도 투표권이 있는 경우, ⅔ 이상의 투표권을 가진 연합이 약속할 수 있습니다. 임의적이고 잘못된 상태입니다. 이것은 (BFT)의 특징입니다. 합의 시스템. 포크를 생성하는 이중 서명과 달리 쉽게 검증할 수 있는 증거를 통해 범죄 행위를 탐지합니다. 유효하지 않은 상태에서는 유효성을 검사하지 않는 피어가 전체 블록을 확인해야 합니다. 이는 상태의 로컬 복사본을 유지하고 실행한다는 것을 의미합니다. 각 트랜잭션에 대해 독립적으로 상태 루트를 계산합니다. 스스로. 일단 감지되면 이러한 오류를 처리할 수 있는 유일한 방법 사회적 합의를 통해서다. 예를 들어, Bitcoin 상황에서 소프트웨어 버그로 인한 분기 여부에 관계없이 실패했습니다(3월과 마찬가지로). 2013) 또는 비잔틴 동작으로 인해 잘못된 상태를 범하는 경우 광부(2015년 7월 기준), 잘 연결된 커뮤니티 기업, 개발자, 광부 및 기타 조직 수동 조치가 무엇인지에 대한 사회적 합의를 확립했습니다.참가자가 네트워크를 치유하는 데 필요합니다. 게다가 이후 Tendermint blockchain의 validator는 다음과 같을 것으로 예상됩니다. 식별 가능하고 유효하지 않은 상태에 대한 약속은 심지어 원하는 경우 법률이나 일부 외부 법률에 의해 처벌될 수 있습니다. ABCI은(는) 전달되는 3가지 기본 메시지 유형으로 구성됩니다. 애플리케이션의 핵심. 애플리케이션은 다음과 같이 응답합니다. 해당 응답 메시지. AppendTx 메시지는 애플리케이션의 작업 도구입니다. 각각 blockchain의 거래가 이 메시지와 함께 전달됩니다. 는 애플리케이션은 수신된 각 트랜잭션을 검증해야 합니다. 현재 상태, 애플리케이션 프로토콜에 대한 AppendTx 메시지, 그리고 거래의 암호화 자격 증명. 검증된 그런 다음 트랜잭션은 애플리케이션 상태를 업데이트해야 합니다. 값을 키 값 저장소에 바인딩하거나 UTXO를 업데이트하여 데이터베이스. CheckTx 메시지는 AppendTx와 유사하지만 거래 검증. Tendermint Core의 mempool 첫 번째 확인 CheckTx와의 거래 유효성, 릴레이만 유효함 동료와의 거래. 응용 프로그램은 증분을 확인할 수 있습니다 nonce를 사용하고 CheckTx 시 오류를 반환합니다. nonce은 오래되었습니다. Commit 메시지는 암호화를 계산하는 데 사용됩니다. 현재 애플리케이션 상태에 대한 약속을 다음 블록 헤더. 여기에는 몇 가지 편리한 속성이 있습니다. 해당 상태 업데이트의 불일치는 이제 다음과 같이 나타납니다. blockchain 프로그래밍의 전체 클래스를 포착하는 포크 오류. 이는 또한 보안 경량의 개발을 단순화합니다. 클라이언트는 Merkle-hash 증거를 확인하여 확인할 수 있습니다. 블록-hash 및 블록-hash은 쿼럼에 의해 서명됩니다. validators (투표권에 따라).
추가 ABCI 메시지를 통해 애플리케이션은 validator 세트를 변경하고 애플리케이션이 높이 및 커밋 투표와 같은 블록 정보. ABCI 요청/응답은 간단한 Protobuf 메시지입니다. 확인 스키마 yle 밖으로. 인수: Data ([]byte) : 요청 트랜잭션 바이트 반품: 코드(uint32): 응답 코드 Data ([]byte) : 결과 바이트(있는 경우) 로그(문자열): 디버그 또는 오류 메시지 사용법:
트랜잭션을 추가하고 실행합니다. 거래가 유효한 경우, CodeType.OK를 반환합니다. 인수: Data ([]byte) : 요청 트랜잭션 바이트 반품: 코드(uint32): 응답 코드 Data ([]byte) : 결과 바이트(있는 경우) 로그(문자열): 디버그 또는 오류 메시지 사용법:
거래를 검증합니다. 이 메시지는 상태. 거래는 이전에 CheckTx를 통해 처음으로 실행됩니다. mempool 계층의 피어에게 브로드캐스팅됩니다. 당신은 만들 수 있습니다 CheckTx 반상태 저장 및 커밋 시 상태 지우기 또는 BeginBlock - 트랜잭션의 종속 시퀀스를 허용합니다. 같은 블록에 있어요.
반품: 데이터([]바이트): 머클 루트 hash 로그(문자열): 디버그 또는 오류 메시지 사용법:
애플리케이션 상태의 머클 루트 hash을 반환합니다. 인수: Data ([]byte) : 쿼리 요청 바이트 반품: 코드(uint32): 응답 코드 Data ([]byte) : 쿼리 응답 바이트 로그(문자열): 디버그 또는 오류 메시지 사용법:
응답 큐를 플러시합니다. 구현하는 애플리케이션 유형. 애플리케이션은 이 메시지를 구현할 필요가 없습니다. 프로젝트에 의해 처리됩니다. 반품: Data ([]byte) : 정보 바이트 사용법:
애플리케이션 상태에 대한 정보를 반환합니다. 신청 특정. 인수: Key (string) : 설정할 키
Value (string) : 키에 설정할 값 반품: 로그(문자열): 디버그 또는 오류 메시지 사용법:
애플리케이션 옵션을 설정합니다. 예: 키=“모드”, 값=“mempool” mempool 연결 또는 Key=“mode”, Value=“consensus” 합의된 연결. 다른 옵션은 애플리케이션에 따라 다릅니다. 인수: 유효성 검사기([]Validator): 초기 생성-validators 사용법:
창세기에 한 번 호출됨 인수: 높이(uint64): 시작되는 블록 높이 사용법:
새로운 블록의 시작을 알립니다. 어떤 일이 일어나기 전에 호출됨 AppendTxs. 인수: 높이(uint64): 끝난 블록 높이 반품: 유효성 검사기([]Validator): validator을 새로 변경했습니다. 투표권(제거하려면 0) 사용법:
블록의 끝을 신호합니다. 결국 각 커밋 전에 호출됩니다. 거래 자세한 내용은 ABCI 저장소를 참조하세요.발신자가 원하는 데에는 여러 가지 이유가 있습니다. 수신 체인에 의한 패킷 전달에 대한 승인. 예를 들어, 보낸 사람이 상태를 알 수 없습니다. 대상 체인에 결함이 있을 것으로 예상되는 경우. 아니면 발신인이 패킷에 시간 초과를 적용하려고 합니다(MaxHeight 사용). 패킷 소리), 대상 체인은 들어오는 숫자의 갑작스러운 급증으로 인해 서비스 거부 공격을 받을 수 있습니다. 패킷. 이 경우 발송인은 배달 확인을 요구할 수 있습니다. 초기 패킷 상태를 AckPending으로 설정합니다. 그렇다면 그것은 다음을 포함하여 체인의 배송 확인 책임을 받습니다. Merkle hash 앱에서는 IBCPacket으로 축약되었습니다. 먼저 IBCBlockCommit 및 IBCPacketTx가 '허브'에 게시됩니다. 이는 'Zone1'에 IBCPacket이 존재함을 증명합니다. 그렇게 말해보세요 IBCPacketTx의 값은 다음과 같습니다. FromChainID : “Zone1” FromBlockHeight : 100 (예:) 패킷: IBC패킷:
헤더: IBCPacketHeader: SrcChainID : “Zone1” DstChainID : “Zone2” 개수 : 200 (말) 상태 : 승인 보류 중 종류 : “코인” MaxHeight : 350 (예: "허브"의 높이는 현재 300입니다) 페이로드 : <“코인” 페이로드의 바이트 수> 다음으로 IBCBlockCommit 및 IBCPacketTx가 'Zone2'에 게시됩니다. 이는 '허브'에 IBC패킷이 존재함을 증명합니다. 그렇게 말해보세요 IBCPacketTx의 값은 다음과 같습니다. FromChainID : “허브” FromBlockHeight : 300 패킷: IBC패킷: 헤더: IBCPacketHeader: SrcChainID : “Zone1” DstChainID : “Zone2” 개수 : 200 상태 : 승인 보류 중 종류 : “코인” 최대 높이 : 350 페이로드 : <“코인” 페이로드의 동일한 바이트> 다음으로, “Zone2”는 앱-hash에 축약된 패킷을 포함해야 합니다. AckSent의 새로운 상태를 보여줍니다. IBCBlockCommit 및 IBCPacketTx는 존재를 증명하는 'Hub'에 다시 게시됩니다. 'Zone2'의 축약된 IBC패킷입니다. IBCPacketTx라고 말하세요 다음과 같은 값을 갖습니다: FromChainID : “Zone2”
FromBlockHeight : 400 (예:) 패킷: IBC패킷: 헤더: IBCPacketHeader: SrcChainID : “Zone1” DstChainID : “Zone2” 개수 : 200 상태 : 승인 전송됨 종류 : “코인” 최대 높이 : 350 PayloadHash : <동일한 "코인" 페이로드의 hash 바이트> 마지막으로 "허브"는 패킷의 상태를 업데이트해야 합니다. AckReceived에 대한 AckPending입니다. 이 새로운 분석 상태에 대한 증거 "Zone2"로 돌아가야 합니다. IBCPacketTx에 다음이 있다고 가정해 보세요. 값: FromChainID : “허브” FromBlockHeight : 301 패킷: IBC패킷: 헤더: IBCPacketHeader: SrcChainID : “Zone1” DstChainID : “Zone2” 개수 : 200 상태 : 수신확인 종류 : “코인” 최대 높이 : 350 PayloadHash : <동일한 "코인" 페이로드의 hash 바이트> 한편, “Zone1”은 성공적인 배송을 낙관적으로 가정할 수 있습니다. 반대 증거가 입증되지 않는 한 "동전" 패킷 "허브". 위 예에서 'Hub'가 AckSent를 받지 못한 경우
블록 350으로 "Zone2"의 상태를 설정했다면 상태가 설정되었을 것입니다. 자동으로 시간 초과가 발생합니다. 시간 초과에 대한 이 증거는 다음과 같습니다. "Zone1"에 다시 게시되며 모든 token이 반환될 수 있습니다. Merkle tree에는 두 가지 유형이 지원됩니다. Tendermint/Cosmos 생태계: 단순 트리 및 IAVL+ 나무. 단순 트리는 요소의 정적 목록에 대한 Merkle tree입니다. 만약 항목 수는 2의 거듭제곱이 아니며 일부 리프는 다른 수준. Simple Tree는 트리의 양쪽 측면을 유지하려고 시도합니다. 높이는 같지만 왼쪽이 하나 더 클 수 있습니다. 이 Merkle tree은(는) 블록의 거래를 Merkle화하는 데 사용되며 최상위 수준 애플리케이션 상태 루트의 요소.IAVL+ 데이터 구조의 목적은 지속적인 정보를 제공하는 것입니다. 애플리케이션 상태의 키-값 쌍에 대한 저장 결정론적 머클 루트 hash은 효율적으로 계산될 수 있습니다. 는 트리는 AVL 알고리즘의 변형을 사용하여 균형을 이루고 있으며 모든 연산은 O(log(n))입니다. AVL 트리에서 모든 노드의 두 하위 하위 트리의 높이는 최대 1개만 다릅니다. 이 조건을 위반할 때마다 업데이트하면 트리는 O(log(n))개의 새 노드를 생성하여 재조정됩니다. 오래된 트리의 수정되지 않은 노드를 가리킵니다. 원래 AVL에서는 알고리즘에서는 내부 노드도 키-값 쌍을 보유할 수 있습니다. AVL+ 알고리즘(+ 참고) AVL 알고리즘을 수정하여 모든 항목을 유지합니다. 리프 노드에 값을 저장하고 분기 노드만 사용하여 키를 저장합니다. 이는 머클 hash 트레일을 유지하면서 알고리즘을 단순화합니다. 짧다. AVL+ 트리는 Ethereum의 Patricia 시도와 유사합니다. 있다 절충. 키를 삽입하기 전에 hash할 필요는 없습니다. IAVL+ 트리 - 키에서 더 빠른 순서의 반복을 제공합니다. 일부 응용 프로그램에 도움이 될 수 있는 공간입니다. 논리는 더 간단하다 내부 노드와 두 가지 유형의 노드만 필요합니다. 잎 노드. 머클 증명은 평균적으로 더 짧습니다. * / \ / \ / \ / \ * * / \ / \ / \ / \ / \ / \ * * * h6 / \ / \ / \ h0 h1 h2 h3 h4 h5 7개 요소로 구성된 SimpleTree
균형 잡힌 이진 트리. 반면에 Merkle 루트는 IAVL+ 트리는 업데이트 순서에 따라 달라집니다. 우리는 다음과 같은 효율적인 Merkle tree을 추가로 지원할 것입니다. 바이너리 변형이 다음과 같은 경우 Ethereum의 Patricia Trie 가능합니다. 표준 구현에서 트랜잭션은 다음으로 스트리밍됩니다. Cosmos ABCI 인터페이스를 통한 허브 애플리케이션. Cosmos 허브는 다수의 기본 거래를 허용합니다. SendTx, BondTx, UnbondTx, ReportHackTx 등의 유형을 포함합니다. SlashTx, BurnAtomTx, ProposalCreateTx 및 ProposalVoteTx, 이는 상당히 자명하며 다음 문서에 문서화됩니다. 이 문서의 향후 개정판. 여기서 우리는 두 가지 기본 사항을 문서화합니다. IBC의 트랜잭션 유형: IBCBlockCommitTx 및 IBCPacketTx. IBCBlockCommitTx 트랜잭션은 다음으로 구성됩니다. ChainID(문자열): blockchain의 ID BlockHash ([]byte): 블록-hash 바이트, Merkle 루트 여기에는 앱-hash이 포함되어 있습니다. BlockPartsHeader(PartSetHeader): 블록 부분 집합 헤더 바이트, 투표 서명을 확인하는 데만 필요함 BlockHeight(int): 커밋 높이 BlockRound(int): 커밋 라운드 Commit ([]Vote) : >⅔ Tendermint Precommit 투표는 블록 커밋으로 구성 ValidatorsHash ([]byte): 새 항목의 머클 트리 루트 hash validator 세트
ValidatorsHashProof(SimpleProof): BlockHash에 대해 ValidatorsHash를 증명하기 위한 SimpleTree Merkleproof
AppHash([]바이트): IAVLTree Merkle-tree 루트 hash
애플리케이션 상태
AppHashProof(SimpleProof): SimpleTree 머클 증명
BlockHash에 대해 AppHash 증명
IBC패킷은 다음으로 구성됩니다.
헤더(IBCPacketHeader): 패킷 헤더
페이로드([]byte): 패킷 페이로드의 바이트입니다. 선택사항
PayloadHash ([]byte) : 패킷 바이트에 대한 hash입니다.
선택사항
Payload 또는 PayloadHash 중 하나가 있어야 합니다. hash
IBCPacket의 는 두 항목 헤더의 간단한 Merkle 루트입니다.
및 페이로드. 전체 페이로드가 없는 IBC패킷을
약칭패킷.
IBCPacketHeader는 다음으로 구성됩니다.
SrcChainID(문자열): 소스 blockchain ID
DstChainID (문자열) : 대상 blockchain ID
Number(int): 모든 패킷의 고유 번호
상태(열거형): AckPending , AckSent 중 하나일 수 있습니다.
AckReceived, NoAck 또는 시간 초과
유형(문자열): 유형은 애플리케이션에 따라 다릅니다. Cosmos
"코인" 패킷 유형을 예약합니다.
MaxHeight(int): 상태가 NoAckWanted 또는 AckReceived가 아닌 경우
이 높이만큼 상태는 Timeout 이 됩니다. 선택사항
IBCPacketTx 트랜잭션은 다음으로 구성됩니다.FromChainID(문자열): blockchain의 ID입니다.
이 패킷을 제공하고; 꼭 출처는 아니어도
FromBlockHeight(int): blockchain 높이입니다.
다음 패킷은 블록-hash에 포함됩니다(머클화).
소스 체인
패킷(IBCPacket): 상태가 1일 수 있는 데이터 패킷입니다.
AckPending , AckSent , AckReceived , NoAck 또는 Timeout
PacketProof(IAVLProof): 증명을 위한 IAVLTree Merkle 증명
소스 체인의 AppHash에 대한 패킷의 hash
주어진 높이
“Zone1”에서 “Zone2”로 패킷을 보내는 순서
"허브"를 통한 방법은 {그림 X}에 나와 있습니다. 먼저, IBCPacketTx
패킷이 앱 상태에 포함되어 있음을 "허브"에 증명합니다.
“구역 1”. 그런 다음 또 다른 IBCPacketTx는 'Zone2'에 대해
패킷은 "허브"의 앱 상태에 포함됩니다. 이 동안
절차에서 IBCPacket 필드는 동일합니다. SrcChainID는 다음과 같습니다.
항상 "Zone1"이고, DstChainID는 항상 "Zone2"입니다.
PacketProof에는 다음과 같이 올바른 Merkle 방지 경로가 있어야 합니다.
다음과 같습니다:
“Zone1”이 “Hub”를 통해 “Zone2”로 패킷을 보내려고 할 때,
IBCPacket 데이터는 패킷이 "Zone1", "Hub" 또는 "Zone2"에서 Merkleized되었는지 여부와 동일합니다. 유일하게 변경 가능한 Yeld는 다음과 같습니다.
배송 추적 상태입니다.
개념화에 도움을 주신 친구와 동료들에게 감사드립니다.
Tendermint와의 작업을 검토하고 지원합니다.
그리고 Cosmos.
IBC/
SkuChain의 Zaki Manian은 형식 지정 및 작업에 많은 도움을 주었습니다. 특히 ABCI 섹션 아래의 문구 Althea의 Jehan Tremback과 Dustin Byington이 도움을 주었습니다. 초기 반복 합의에 대한 피드백을 주신 Honey Badger의 Andrew Miller 합의와 표현에 대한 피드백을 주신 Greg Slepak 또한 다양한 활동을 해주신 Bill Gleim과 한승환에게도 감사드립니다. 기여. 귀하의 기여를 위해 여기에 귀하의 이름과 조직이 표시됩니다. 1 Bitcoin: https://bitcoin.org/bitcoin.pdf 2 제로캐시: http://zerocash-project.org/paper 3 Ethereum: https://github.com/ethereum/wiki/wiki/WhitePaper 4 DAO: https://download.slock.it/public/DAO/WhitePaper.pdf 5 분리된 증인: https://github.com/bitcoin/bips/blob/master/bip0141.mediawiki 6 BitcoinNG: https://arxiv.org/pdf/1510.02037v2.pdf 7 라이트닝 네트워크: https://lightning.network/lightningnetwork-paper-DRAFT-0.5.pdf 8 텐더민트: https://github.com/tendermint/tendermint/wiki 9 FLP 불가능: https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf 10 슬래셔: https://blog.ethereum.org/2014/01/15/slasher-apunitive-proof-of-stake-algorithm/ 11 PBFT: http://pmg.csail.mit.edu/papers/osdi99.pdf 12 비트셰어: https://bitshares.org/technology/delegatedproof-of-stake-consensus/
13 Stellar: https://www.stellar.org/papers/stellar-consensusprotocol.pdf 14 중개인: https://interledger.org/rfcs/0001-interledgerarchitecture/ 15개의 사이드체인: https://blockstream.com/sidechains.pdf 16 캐스퍼: https://blog.ethereum.org/2015/08/01/introducing-casperfriendly-ghost/ 17 ABCI: https://github.com/tendermint/abci 18 Ethereum 샤딩: https://github.com/ethereum/EIPs/issues/53 19 LibSwift: http://www.ds.ewi.tudelft.nl/yleadmin/pds/papers/Performa nceAnalyticOfLibswift.pdf 20DLS: http://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf 21 씬 클라이언트 보안: https://en.bitcoin.it/wiki/Thin_Client_Security 22 Ethereum 2.0 연보라색 종이: http://vitalik.ca/yles/mauve_paper.html https://www.docdroid.net/ec7xGzs/314477721-ethereumplatform-review-opportunities-and-challenges-for-privateand-consortium-blockchains.pdf.html
¼ è
الإجماع والتفاصيل الفنية
ينبغي لبروتوكول الإجماع المصمم جيدًا أن يوفر بعضًا من ذلك الضمانات في حالة تجاوز قدرة التسامح ويفشل الإجماع. وهذا ضروري بشكل خاص في المجال الاقتصادي الأنظمة، حيث يمكن أن يكون للسلوك البيزنطي قدر كبير من المال مكافأة. وأهم هذه الضمانات هو شكل من أشكال المساءلة، حيث تتم العمليات التي تسببت في الإجماع الفشل (أي جعل عملاء البروتوكول يقبلون قيمًا مختلفة - أ fork) يمكن تحديد هويته ومعاقبته وفقًا لقواعد البروتوكول، أو ربما النظام القانوني. عندما يكون النظام القانوني يمكن أن يكون استدعاء validators غير موثوق به أو باهظ التكلفة اضطروا إلى تقديم ودائع ضمان من أجل المشاركة، وهؤلاء يمكن إلغاء الودائع أو تخفيضها عند حدوث سلوك ضار تم اكتشاف [10]. لاحظ أن هذا يختلف عن Bitcoin، حيث يكون التفرع حدثًا منتظمًا بسبب عدم تزامن الشبكة والطبيعة الاحتمالية للنهاية الاصطدامات الجزئية hash. نظرًا لأنه في كثير من الحالات يكون هناك شوكة ضارة لا يمكن تمييزه عن الشوكة بسبب عدم التزامن، Bitcoin لا يمكن تنفيذ مسؤولية الشوكة بشكل موثوق، بخلاف الضمنية تكلفة الفرصة البديلة التي يدفعها عمال المناجم لتعدين كتلة معزولة. نحن نطلق على مرحلتي التصويت PreVote وPreCommit. يمكن التصويت ل كتلة معينة أو لا شيء. نحن نطلق على مجموعة من >⅔ الأصوات المسبقة لكتلة واحدة في نفس الجولة رقصة البولكا، ومجموعة من >⅔ الالتزام المسبق لكتلة واحدة في نفس جولة الالتزام. إذا> ⅔ الالتزام المسبق لـ Nil في نفس الجولة، ينتقلون إلى الجولة التالية جولة. لاحظ أن الحتمية الصارمة في البروتوكول تنطوي على ضعف يجب اكتشاف افتراض التزامن كقادة خاطئين
تم تخطيه. ومن ثم، ينتظر validators بعض الوقت، TimeoutPropose، قبل أن يصوتوا على Nil، وقيمة TimeoutPropose يزيد مع كل جولة. التقدم من خلال بقية الجولة غير متزامنة تمامًا، في هذا التقدم فقط يتم إجراؤه بمجرد سماع validator من >⅔ الشبكة. في الممارسة العملية، سوف يتطلب الأمر وجود خصم قوي للغاية لإحباطه إلى أجل غير مسمى افتراض التزامن الضعيف (مما يتسبب في فشل الإجماع من أي وقت مضى ارتكاب كتلة)، والقيام بذلك يمكن أن يتم أكثر من ذلك من الصعب استخدام القيم العشوائية لـ TimeoutPropose في كل منها validator. هناك مجموعة إضافية من القيود، أو قواعد القفل، تضمن أن ستلتزم الشبكة في النهاية بكتلة واحدة فقط عند كل ارتفاع. أي محاولة خبيثة للتسبب في ارتكاب أكثر من كتلة واحدة على ارتفاع معين يمكن تحديدها. أولاً، الالتزام المسبق للكتلة يجب أن يأتي مع مبرر، في شكل رقصة البولكا لتلك الكتلة. إذا كان validator قد قام بالفعل بتنفيذ كتلة في الجولة R_1، فإننا ويقول أنهم مقفلون على تلك الكتلة، ويستخدم رقصة البولكا لتبرير يجب أن يأتي الالتزام المسبق الجديد في الجولة R_2 في جولة R_polka حيث R_1 < R_polka <= R_2. ثانيًا، يجب أن يقترح validators و/أو قم بالتصويت المسبق على الكتلة التي تم قفلها عليها. معا، هؤلاء تضمن الشروط أن validator لا يتم الالتزام المسبق بدونه أدلة كافية لتبرير ذلك، وأن validators التي لديها بالفعل لا يمكن لـ PreCommit المساهمة في الأدلة المقدمة إلى PreCommit شيء آخر. وهذا يضمن سلامة وحيوية الجسم خوارزمية الإجماع. يتم وصف التفاصيل الكاملة للبروتوكول هنا. يتم التخلص من الحاجة إلى مزامنة جميع رؤوس الكتل في TendermintPoS حيث أن وجود سلسلة بديلة (شوكة) يعني ≥⅓ من يمكن خفض الحصة المستعبدة. بالطبع، لأن القطع يتطلب أن يشارك شخص ما دليلاً على الشوكة، يجب على العملاء الخفيفين تخزينها أي كتلة-hash ترتكب ما تراه. بالإضافة إلى العملاء الخفيفينيمكن أن تظل متزامنة بشكل دوري مع التغييرات التي يتم إجراؤها على مجموعة validator، في لتجنب الهجمات بعيدة المدى (ولكن الحلول الأخرى هي ممكن). بروح مشابهة لـ Ethereum، يتيح Tendermint للتطبيقات القيام بذلك قم بتضمين جذر Merkle العالمي hash في كل كتلة، مما يسمح بذلك بسهولة استعلامات حالة يمكن التحقق منها لأشياء مثل أرصدة الحسابات، والقيمة المخزنة في العقد، أو وجود معاملة غير منفقة الإخراج، اعتمادا على طبيعة التطبيق. بافتراض وجود مجموعة مرنة بما فيه الكفاية من شبكات البث ومجموعة validator ثابتة، أي شوكة في blockchain يمكن أن تكون تم اكتشافها وخفض رواسب validators المخالفة. هذا الابتكار، الذي اقترحه فيتاليك بوتيرين لأول مرة في أوائل عام 2014، يحل المشكلة مشكلة عدم وجود شيء على المحك للآخرين proof-of-stake العملات المشفرة (انظر الأعمال ذات الصلة). ومع ذلك، منذ validator مجموعات يجب أن تكون قادرة على تغيير الأصل، على مدى فترة طويلة من الزمن قد يصبح جميع validators غير مقيدين، وبالتالي سيكونون أحرارًا في ذلك إنشاء سلسلة جديدة من كتلة التكوين، دون تحمل أي تكلفة لم يعد لديهم ودائع مقفلة. وجاء هذا الهجوم ليكون المعروف باسم الهجوم بعيد المدى (LRA)، على عكس الهجوم القصير هجوم النطاق، حيث يتسبب validators المرتبطين حاليًا في حدوث أ شوكة ومن ثم يعاقب عليها (بافتراض وجود شوكة مسؤولة BFT خوارزمية مثل إجماع Tendermint). الهجمات بعيدة المدى هي غالبًا ما يُعتقد أنها بمثابة ضربة حاسمة لـ proof-of-stake. ولحسن الحظ، يمكن التخفيف من حدة جيش الرب للمقاومة على النحو التالي. أولا بالنسبة ل validator لإلغاء الارتباط (وبالتالي استرداد وديعة الضمان الخاصة بهم ولم يعد يكسب رسوم المشاركة في الإجماع). يجب أن تكون الوديعة غير قابلة للتحويل لفترة من الوقت المعروفة باسم "فترة التفكيك"، والتي قد تكون في حدود أسابيع أو أشهر. ثانيًا، لكي يكون العميل الخفيف آمنًا، الأول عند اتصاله بالشبكة، يجب عليه التحقق من الحظر الأخير-hash ضد مصدر موثوق به، أو يفضل عدة مصادر. هذا
يُشار إلى الحالة أحيانًا باسم "الذاتية الضعيفة". وأخيرا، لكي يظل آمنًا، يجب أن تتم مزامنته مع أحدث validator المعين في على الأقل بشكل متكرر مثل طول فترة فك الارتباط. هذا يضمن أن العميل الخفيف يعرف التغييرات التي تم إجراؤها على validator تم تعيينه قبل validator وقد تم إلغاء رأس ماله وبالتالي لم يعد كذلك على المحك، مما يسمح لها بخداع العميل بتنفيذها هجوم بعيد المدى عن طريق إنشاء كتل جديدة تبدأ من مرة أخرى الارتفاع حيث تم ربطه (بافتراض أنه يتحكم بشكل كافٍ العديد من المفاتيح الخاصة المبكرة). لاحظ أن التغلب على جيش الرب للمقاومة بهذه الطريقة يتطلب إصلاحًا شاملاً نموذج الأمان الأصلي لـ proof-of-work. في إثبات العمل، هو كذلك من المفترض أن العميل الخفيف يمكنه المزامنة مع الارتفاع الحالي من كتلة التكوين الموثوق بها في أي وقت ببساطة عن طريق معالجة إثبات العمل في كل رأس كتلة. ولكن للتغلب على جيش الرب للمقاومة، علينا تتطلب أن يأتي العميل الخفيف عبر الإنترنت مع بعض الانتظام تتبع التغييرات في مجموعة validator، وذلك في المرة الأولى التي يتم فيها ذلك متصلين بالإنترنت ويجب عليهم أن يكونوا حريصين بشكل خاص على المصادقة ما يسمعونه من الشبكة ضد مصادر موثوقة. من بالطبع، هذا المتطلب الأخير مشابه لمتطلب Bitcoin، حيث ويجب أيضًا الحصول على البروتوكول والبرمجيات من جهة موثوقة المصدر. الطريقة المذكورة أعلاه لمنع جيش الرب للمقاومة مناسبة تمامًا لـ validators والعقد الكاملة لـ blockchain التي تعمل بنظام Tendermint لأن هذه من المفترض أن تظل العقد متصلة بالشبكة. ال الطريقة مناسبة أيضًا للعملاء الخفيفين الذين يمكن توقعهم المزامنة مع الشبكة بشكل متكرر. ومع ذلك، بالنسبة للعملاء الخفيفين ليس من المتوقع أن يكون لديك إمكانية الوصول المتكرر إلى الإنترنت أو blockchain الشبكة، ولكن يمكن استخدام حل آخر للتغلب عليها جيش الرب للمقاومة. يمكن لحاملي غير validator token نشر tokens باسمهم الضمانات ذات فترة فك الارتباط طويلة جدًا (على سبيل المثال، أطول بكثير من فترة إلغاء الارتباط لـ validators) وخدمة العملاء الخفيفين مع طريقة ثانوية لإثبات صحة التيار و الكتلة الماضية-hashes. في حين أن هذه tokens لا يتم احتسابها ضمن أمان إجماع blockchain، ومع ذلك يمكنهم ذلكتقديم ضمانات قوية للعملاء الخفيفين. إذا كانت الكتلة التاريخية-hash تم دعم الاستعلام في Ethereum، ويمكن لأي شخص ربطه tokens في smart contract المصممة خصيصًا وتقديمها خدمات التصديق مقابل الأجر، مما يؤدي بشكل فعال إلى إنشاء سوق لأمن LRA من عملاء Lightclient. نظرًا لتعريف التزام الكتلة، فإن أي ≥⅓ تحالف من يمكن لقوة التصويت أن توقف blockchain بالذهاب إلى الخارج أم لا بث أصواتهم يمكن لمثل هذا التحالف أيضًا فرض الرقابة معاملات معينة عن طريق رفض الكتل التي تتضمن هذه المعاملات المعاملات، على الرغم من أن هذا من شأنه أن يؤدي إلى نسبة كبيرة من مقترحات الكتلة التي سيتم رفضها، الأمر الذي من شأنه أن يبطئ المعدل من عمليات تنفيذ الحظر لـ blockchain، مما يقلل من فائدته وقيمته. قد يقوم التحالف الخبيث أيضًا ببث الأصوات بشكل متقطع كما أن طحن كتلة blockchain تلتزم بالتوقف القريب أو الانخراط أي مزيج من هذه الهجمات. وأخيرا، يمكن أن يسبب blockchain إلى الشوكة، بالتوقيع المزدوج أو انتهاك القفل القواعد. وإذا شارك أيضًا خصم نشط عالميًا، فيمكنه التقسيم الشبكة بطريقة قد تبدو خاطئة كانت مجموعة فرعية من validators مسؤولة عن التباطؤ. هذا ليس كذلك مجرد قيود على Tendermint، بل هي قيود على الجميع بروتوكولات الإجماع التي من المحتمل أن يتم التحكم في شبكتها بواسطة الخصم النشط. بالنسبة لهذه الأنواع من الهجمات، ينبغي لمجموعة فرعية من validators التنسيق من خلال وسائل خارجية للتوقيع على مقترح إعادة التنظيم يختار شوكة (وأي دليل على ذلك) والمجموعة الفرعية الأولية من validators مع توقيعاتهم. يتخلى المصادقون الذين يوقعون على مقترح إعادة التنظيم هذا عن ضماناتهم على جميع الشوكات الأخرى. يجب على العملاء التحقق من التوقيعات على مقترح إعادة التنظيم، والتحقق من أي دليل، وإصدار حكم أو مطالبة المستخدم النهائي باتخاذ قرار. ل على سبيل المثال، قد يطلب تطبيق محفظة الهاتف من المستخدم توفير الأمان
تحذير، في حين أن الثلاجة قد تقبل أي اقتراح لإعادة التنظيم موقعة من +½ من أصل validators بقوة التصويت. لا يمكن أن تأتي خوارزمية بيزنطية غير متزامنة متسامحة مع الأخطاء إلى الإجماع عندما يكون ≥⅓ من قوة التصويت غير شريفة، ومع ذلك فهو شوكة يفترض أن ≥⅓ من قوة التصويت كانت غير شريفة بالفعل التوقيع المزدوج أو تغيير القفل دون مبرر. لذلك، التوقيع إن اقتراح إعادة التنظيم يمثل مشكلة تنسيق لا يمكن حلها يتم حلها بواسطة أي بروتوكول غير متزامن (أي تلقائيًا، و دون وضع افتراضات حول موثوقية الشبكة الأساسية). في الوقت الحالي، نترك مشكلة تنسيق إعادة التنظيم للتنسيق البشري من خلال الإجماع الاجتماعي على وسائل الإعلام عبر الإنترنت. يجب على المصادقين الحرص على التأكد من ذلك لا توجد أقسام شبكة متبقية قبل التوقيع على اقتراح إعادة التنظيم، لتجنب المواقف التي يتم فيها التوقيع على اقتراحين متعارضين لإعادة التنظيم. على افتراض أن وسيلة التنسيق الخارجي والبروتوكول قوية، ويترتب على ذلك أن الشوكات أقل إثارة للقلق من الرقابة الهجمات. بالإضافة إلى الشوكة والرقابة التي تتطلب ≥⅓ البيزنطية قوة التصويت، قد يلتزم ائتلاف من >⅔ قوة التصويت حالة تعسفية وغير صالحة. وهذه هي سمة أي (BFT) نظام الإجماع. على عكس التوقيع المزدوج الذي يخلق الشوكات بأدلة يمكن التحقق منها بسهولة، والكشف عن ارتكاب جريمة ما تتطلب الحالة غير الصالحة أن يقوم أقران لم يتم التحقق من صحتهم بالتحقق من الكتل بأكملها، مما يعني أنهم يحتفظون بنسخة محلية من الدولة وينفذونها كل معاملة، وحساب جذر الدولة بشكل مستقل ل أنفسهم. وبمجرد الكشف عنها، فإن الطريقة الوحيدة للتعامل مع مثل هذا الفشل يتم عن طريق الإجماع الاجتماعي. على سبيل المثال، في المواقف التي يكون فيها Bitcoin قد فشل، سواء كان التفرع بسبب أخطاء برمجية (كما في مارس 2013)، أو ارتكاب حالة باطلة بسبب السلوك البيزنطي عمال المناجم (كما في يوليو 2015)، مجتمع متصل جيدًا بـ الشركات والمطورين وعمال المناجم وغيرها من المنظمات أنشأ إجماعًا اجتماعيًا حول ماهية الإجراءات اليدويةالمطلوبة من قبل المشاركين لشفاء الشبكة. وعلاوة على ذلك، منذ من المتوقع أن يكون validators من النعناع blockchain يمكن تحديدها، بل قد يكون التزام دولة غير صالحة يعاقب عليها القانون أو بعض الاجتهادات القضائية الخارجية، إذا رغبت في ذلك. ABCI يتكون من 3 أنواع رسائل أساسية يتم تسليمها منها جوهر التطبيق. التطبيق يجيب ب رسائل الرد المقابلة. تعتبر رسالة AppendTx بمثابة العمود الفقري للتطبيق. كل يتم تسليم المعاملة في blockchain مع هذه الرسالة. ال يحتاج التطبيق إلى التحقق من صحة كل المعاملات الواردة مع رسالة AppendTx مقابل الحالة الحالية، وبروتوكول التطبيق، وبيانات اعتماد التشفير للمعاملة. تم التحقق من صحتها تحتاج المعاملة بعد ذلك إلى تحديث حالة التطبيق — بواسطة ربط قيمة في مخزن القيم الأساسية، أو عن طريق تحديث UTXO قاعدة البيانات. تشبه رسالة CheckTx رسالة AppendTx، ولكنها مخصصة فقط لـ التحقق من صحة المعاملات. الشيكات الأولى لذاكرة Tendermint Core صلاحية المعاملة مع CheckTx، والمرحلات صالحة فقط المعاملات لأقرانها. قد تحقق التطبيقات زيادة nonce في المعاملة وإرجاع خطأ عند CheckTx إذا كان nonce قديم. يتم استخدام رسالة Commit لحساب التشفير الالتزام بحالة التطبيق الحالية، ليتم وضعها في رأس الكتلة التالي. هذا له بعض الخصائص المفيدة. ستظهر الآن التناقضات في تحديث تلك الحالة blockchain شوكات تلتقط فئة كاملة من البرمجة أخطاء. وهذا أيضًا يبسط عملية تطوير آمنة وخفيفة الوزن العملاء، حيث يمكن التحقق من أدلة Merkle-hash عن طريق التحقق منها الكتلة-hash، والكتلة-hash تم توقيعها بنصاب قانوني validators (حسب قوة التصويت).
تسمح رسائل ABCI الإضافية للتطبيق بتتبعها وقم بتغيير مجموعة validator، ولكي يحصل التطبيق على معلومات الحظر، مثل الارتفاع وأصوات الالتزام. ABCI الطلبات/الردود هي رسائل Protobuf بسيطة. تحقق خارج المخطط. الحجج: البيانات ([]بايت): بايتات معاملة الطلب العوائد: الرمز (uint32): رمز الاستجابة البيانات ([]بايت): بايتات النتيجة، إن وجدت السجل (سلسلة): تصحيح الأخطاء أو رسالة الخطأ الاستخدام:
إلحاق المعاملة وتشغيلها. إذا كانت الصفقة صحيحة ترجع CodeType.OK الحجج: البيانات ([]بايت): بايتات معاملة الطلب العوائد: الرمز (uint32): رمز الاستجابة البيانات ([]بايت): بايتات النتيجة، إن وجدت السجل (سلسلة): تصحيح الأخطاء أو رسالة الخطأ الاستخدام:
التحقق من صحة المعاملة. لا ينبغي أن تتحور هذه الرسالة الدولة. يتم تشغيل المعاملات لأول مرة من خلال CheckTx من قبل البث إلى أقرانهم في طبقة mempool. يمكنك صنع CheckTx شبه حالة ومسح الحالة عند الالتزام أو BeginBlock، للسماح بتسلسلات المعاملات التابعة في نفس الكتلة.
العوائد: البيانات ([]بايت): جذر Merkle hash السجل (سلسلة): تصحيح الأخطاء أو رسالة الخطأ الاستخدام:
قم بإرجاع جذر Merkle hash لحالة التطبيق. الحجج: البيانات ([]بايت): بايتات طلب الاستعلام العوائد: الرمز (uint32): رمز الاستجابة البيانات ([]بايت): بايت استجابة الاستعلام السجل (سلسلة): تصحيح الأخطاء أو رسالة الخطأ الاستخدام:
مسح قائمة انتظار الاستجابة. التطبيقات التي تنفذ أنواع.لا يحتاج التطبيق إلى تنفيذ هذه الرسالة - إنه كذلك يعالجها المشروع. العوائد: البيانات ([]بايت): بايت المعلومات الاستخدام:
إرجاع معلومات حول حالة التطبيق. التطبيق com.speciyc. الحجج: المفتاح (سلسلة): مفتاح للضبط
القيمة (سلسلة): القيمة المطلوب تعيينها للمفتاح العوائد: السجل (سلسلة): تصحيح الأخطاء أو رسالة الخطأ الاستخدام:
ضبط خيارات التطبيق. على سبيل المثال. المفتاح = "الوضع"، القيمة = "mempool" لـ اتصال mempool، أو المفتاح = "الوضع"، القيمة = "الإجماع" لـ اتصال توافقي. الخيارات الأخرى هي تطبيق محدد. الحجج: أدوات التحقق من الصحة ([] أداة التحقق من الصحة): التكوين الأولي-validators الاستخدام:
دعا مرة واحدة في سفر التكوين الحجج: الارتفاع (uint64) : ارتفاع الكتلة الذي يبدأ الاستخدام:
يشير إلى بداية كتلة جديدة. دعا قبل أي إلحاقTxs. الحجج: الارتفاع (uint64) : ارتفاع الكتلة الذي انتهى العوائد: أدوات التحقق ([]أداة التحقق) : تم تغيير validators بأخرى جديدة صلاحيات التصويت (0 لإزالة) الاستخدام:
إشارات نهاية الكتلة. تم الاتصال به قبل كل التزام بعد كل شيء المعاملات راجع مستودع ABCI لمزيد من التفاصيل.هناك عدة أسباب وراء رغبة المرسل في الحصول على إقرار بتسليم الحزمة من خلال سلسلة الاستقبال. على سبيل المثال، قد لا يعرف المرسل حالة الملف سلسلة الوجهة، إذا كان من المتوقع أن تكون معيبة. أو يجوز للمرسل تريد فرض مهلة على الحزمة (باستخدام MaxHeight packet yeld)، في حين أن أي سلسلة وجهة قد تعاني من هجوم رفض الخدمة مع ارتفاع مفاجئ في عدد الرسائل الواردة الحزم. في هذه الحالات، يمكن للمرسل أن يطلب إقرار التسليم من خلال تعيين حالة الحزمة الأولية على AckPending. ثم، هو مسؤولية سلسلة الاستلام عن التسليم عن طريق تضمين يُختصر IBCPacket في تطبيق Merkle hash. أولاً، تم نشر IBCBlockCommit و IBCPacketTx على "Hub" مما يثبت وجود IBCPacket على "Zone1". قل ذلك IBCPacketTx له القيمة التالية: من معرف السلسلة: "المنطقة 1" من بلوك الارتفاع: 100 (على سبيل المثال) الحزمة : IBC الحزمة :
الرأس: IBCرأس الحزمة: معرف SrcChain: "المنطقة 1" معرف DstChain: "المنطقة 2" الرقم: 200 (قل) الحالة: قيد الانتظار النوع: "عملة" MaxHeight : 350 (قل "Hub" حاليًا على ارتفاع 300) الحمولة: <بايتات الحمولة "العملة"> بعد ذلك، يتم نشر IBCBlockCommit و IBCPacketTx على "Zone2" مما يثبت وجود IBCPacket على "Hub". قل ذلك IBCPacketTx له القيمة التالية: FromChainID: "المركز" من ارتفاع الكتلة: 300 الحزمة : IBC الحزمة : الرأس: IBCPacketHeader: معرف SrcChain: "المنطقة 1" معرف DstChain: "المنطقة 2" العدد : 200 الحالة: قيد الانتظار النوع: "عملة" أقصى ارتفاع: 350 الحمولة: <نفس وحدات البايت لحمولة "العملة"> بعد ذلك، يجب أن تتضمن "Zone2" في تطبيقها-hash حزمة مختصرة الذي يوضح الحالة الجديدة لـ AckSent. IBCBlockCommit و IBCPacketTx تم نشرها مرة أخرى على "Hub" مما يثبت وجودها من IBCPacket المختصرة في "Zone2". قل ذلك IBCPacketTx له القيمة التالية: من معرف السلسلة: "المنطقة 2"
من بلوك الارتفاع: 400 (على سبيل المثال) الحزمة : IBC الحزمة : الرأس: IBCرأس الحزمة: معرف SrcChain: "المنطقة 1" معرف DstChain: "المنطقة 2" العدد : 200 الحالة: تم الإرسال النوع: "عملة" أقصى ارتفاع: 350 PayloadHash : <البايتات hash من نفس الحمولة النافعة "للعملة"> وأخيرًا، يجب على "Hub" تحديث حالة الحزمة من "AckPending" إلى "AckReceived". دليل على هذا الوضع الجديد ynalized يجب أن يعود إلى "المنطقة 2". لنفترض أن IBCPacketTx يحتوي على ما يلي القيمة: FromChainID: "المركز" من ارتفاع الكتلة: 301 الحزمة : IBC الحزمة : الرأس: IBCرأس الحزمة: معرف SrcChain: "المنطقة 1" معرف DstChain: "المنطقة 2" العدد : 200 الحالة: تم الاستلام النوع: "عملة" أقصى ارتفاع: 350 PayloadHash : <البايتات hash من نفس الحمولة النافعة "للعملة"> وفي الوقت نفسه، قد تفترض "المنطقة 1" بشكل متفائل التسليم الناجح حزمة "النقود المعدنية" ما لم يثبت خلاف ذلك "المحور". في المثال أعلاه، إذا لم يتلق "Hub" رسالة AckSent
الحالة من "المنطقة 2" بواسطة الكتلة 350، كانت ستحدد الحالة تلقائيًا إلى المهلة. يمكن الحصول على هذا الدليل على المهلة تم نشرها مرة أخرى على "Zone1"، ويمكن إرجاع أي tokens. هناك نوعان من Merkle trees مدعومان في النظام البيئي Tendermint/Cosmos: الشجرة البسيطة وIAVL+ شجرة. الشجرة البسيطة هي Merkle tree لقائمة ثابتة من العناصر. إذا عدد العناصر ليس قوة اثنين، وبعض الأوراق ستكون في مستويات مختلفة. تحاول Simple Tree الحفاظ على جانبي الشجرة نفس الارتفاع، ولكن اليسار قد يكون أكبر من ذلك. هذا Merkle tree هو يستخدم لـ Merkle-ize معاملات الكتلة والمستوى الأعلى عناصر جذر حالة التطبيق.الغرض من بنية بيانات IAVL+ هو توفير الدعم المستمر تخزين أزواج القيمة الرئيسية في حالة التطبيق بحيث يكون أ يمكن حساب جذر Merkle الحتمي hash بكفاءة. ال تتم موازنة الشجرة باستخدام البديل من خوارزمية AVL، وجميع العمليات هي O(log(n)). في شجرة AVL، ارتفاعات الشجرتين الفرعيتين لأي عقدة تختلف بواحدة على الأكثر. كلما تم انتهاك هذا الشرط على التحديث، يتم إعادة توازن الشجرة عن طريق إنشاء العقد الجديدة O(log(n)) التي أشر إلى العقد غير المعدلة من الشجرة القديمة. في AVL الأصلي الخوارزمية، يمكن للعقد الداخلية أيضًا الاحتفاظ بأزواج القيمة الرئيسية. ايه في ال+ الخوارزمية (لاحظ الزائد) تقوم بتعديل خوارزمية AVL للاحتفاظ بكل شيء القيم على العقد الطرفية، مع استخدام العقد الفرعية فقط لتخزين المفاتيح. يؤدي هذا إلى تبسيط الخوارزمية مع الحفاظ على مسار Merkle hash قصيرة. تشبه شجرة AVL+ محاولات باتريشيا Ethereum. هناك المقايضات. لا يلزم أن تكون المفاتيح hashed قبل إدراجها أشجار IAVL+، مما يوفر تكرارًا مرتبًا بشكل أسرع في المفتاح المساحة التي قد تفيد بعض التطبيقات. المنطق هو أبسط ل تنفيذ، يتطلب نوعين فقط من العقد - العقد الداخلية و العقد الورقية. إن برهان ميركل أقصر في المتوسط، كونه أ * / \ / \ / \ / \ * * / \ / \ / \ / \ / \ / \ * * * h6 / \ / \ / \ h0 h1 h2 h3 h4 h5 شجرة بسيطة تحتوي على 7 عناصر
شجرة ثنائية متوازنة من ناحية أخرى، جذر ميركل ل تعتمد شجرة IAVL+ على ترتيب التحديثات. سوف ندعم المزيد من Merkle trees، مثل Ethereum باتريشيا تري عندما يصبح المتغير الثنائي متاح. في التنفيذ الأساسي، يتم تدفق المعاملات إلى Cosmos تطبيق المحور عبر واجهة ABCI. سيقبل Cosmos Hub عددًا من المعاملات الأساسية الأنواع، بما في ذلك SendTx ، BondTx ، UnbondTx ، ReportHackTx ، SlashTx، وBurnAtomTx، وProposalCreateTx، وProposalVoteTx، والتي لا تحتاج إلى شرح إلى حد ما وسيتم توثيقها في ملف المراجعة المستقبلية لهذه الورقة. هنا نقوم بتوثيق الأمرين الأساسيين أنواع المعاملات لـ IBC: IBCBlockCommitTx و IBCPacketTx . تتكون معاملة IBCBlockCommitTx من: ChainID (سلسلة): معرف blockchain BlockHash ([]بايت): الكتلة-hash بايت، جذر Merkle والذي يتضمن التطبيق-hash BlockPartsHeader (PartSetHeader): رأس مجموعة أجزاء الكتلة البايتات، مطلوبة فقط للتحقق من توقيعات التصويت BlockHeight (int) : ارتفاع الالتزام BlockRound (int): جولة الالتزام الالتزام ([]تصويت) : يصوت >⅔ Tendermint Precommit على ذلك تتضمن التزامًا بالكتلة ValidatorsHash ([]بايت): جذر شجرة ميركل hash للجديد validator مجموعة
ValidatorsHashProof (SimpleProof): SimpleTree Merkleproof لإثبات ValidatorsHash مقابل BlockHash
AppHash ([]بايت): جذر شجرة IAVLTree Merkle hash لـ
حالة التطبيق
AppHashProof (SimpleProof): أداة SimpleTree Merkle-proof لـ
إثبات AppHash مقابل BlockHash
تتكون الحزمة IBCPacket من:
Header (IBCPacketHeader): رأس الحزمة
الحمولة ([]بايت): بايتات حمولة الحزمة. اختياري
PayloadHash ([]بايت): hash لبايتات الحزمة.
اختياري
يجب أن يكون أي من Payload أو PayloadHash موجودًا. hash
IBCPacket هو جذر Merkle البسيط للعنصرين، الرأس
و الحمولة. يُطلق على IBCPacket بدون الحمولة الكاملة اسم
الحزمة المختصرة.
يتكون IBCPacketHeader من:
SrcChainID (سلسلة): معرف المصدر blockchain
DstChainID (سلسلة): معرف الوجهة blockchain
الرقم (int) : رقم فريد لجميع الحزم
الحالة (التعداد): يمكن أن تكون واحدة من AckPending أو AckSent أو
AckReceived أو NoAck أو Timeout
النوع (سلسلة): تعتمد الأنواع على التطبيق. Cosmos
يحتفظ بنوع الحزمة "العملة المعدنية".
MaxHeight (int) : إذا كانت الحالة ليست NoAckWanted أو AckReceived
وبهذا الارتفاع، تصبح الحالة Timeout . اختياري
تتكون معاملة IBCPacketTx من:FromChainID (سلسلة): معرف blockchain وهو
توفير هذه الحزمة؛ ليس بالضرورة المصدر
FromBlockHeight (int) : الارتفاع blockchain الذي يوجد فيه
تم تضمين الحزمة التالية (بحجم Merkle) في الكتلة-hash من
سلسلة المصدر
الحزمة (IBCPacket): حزمة من البيانات، قد تكون حالتها واحدة
AckPending أو AckSent أو AckReceived أو NoAck أو Timeout
PacketProof (IAVLProof): IAVLTree Merkle-proof للإثبات
الحزمة hash مقابل AppHash لسلسلة المصدر في
ارتفاع معين
تسلسل إرسال الحزمة من "Zone1" إلى "Zone2"
من خلال "المحور" كما هو موضح في {الشكل X}. أولاً، IBCPacketTx
يثبت لـ "Hub" أن الحزمة مضمنة في حالة التطبيق
"المنطقة 1". بعد ذلك، يثبت IBCPacketTx آخر لـ "Zone2" أن
يتم تضمين الحزمة في حالة التطبيق "Hub". خلال هذا
الإجراء، تكون حقول IBCPacket متطابقة: SrcChainID هو
دائمًا "Zone1"، ويكون DstChainID دائمًا "Zone2".
يجب أن يشتمل PacketProof على المسار الصحيح لـ Merkle-proof، مثل
يلي:
عندما يريد "Zone1" إرسال حزمة إلى "Zone2" من خلال "Hub"،
تكون بيانات IBCPacket متطابقة سواء كانت الحزمة Merkleized على "Zone1" أو "Hub" أو "Zone2". الحقل الوحيد القابل للتغيير هو
الحالة لتتبع التسليم.
ونشكر أصدقائنا وزملائنا الذين ساعدونا في وضع المفهوم،
مراجعة وتقديم الدعم لعملنا مع Tendermint
و Cosmos.
IBC/
قدم زكي مانيان من SkuChain الكثير من المساعدة في التنسيق والتنسيق الصياغة، خاصة ضمن القسم ABCI جيهان تريمباك من ألثيا وداستن بينجتون للمساعدة التكرارات الأولية أندرو ميلر من Honey Badger للحصول على تعليقات حول الإجماع جريج سليباك للحصول على تعليقات بشأن الإجماع والصياغة شكرًا أيضًا لبيل جليم وسيونغهوان هان على جهودهما المتنوعة المساهمات. اسمك ومنظمتك هنا لمساهمتك 1 Bitcoin: https://bitcoin.org/bitcoin.pdf 2 زيرو كاش: http://zerocash-project.org/paper 3 Ethereum: https://github.com/ethereum/wiki/wiki/WhitePaper 4 DAO: https://download.slock.it/public/DAO/WhitePaper.pdf 5 الشاهد المنفصل: https://github.com/bitcoin/bips/blob/master/bip0141.mediawiki 6 BitcoinNG: https://arxiv.org/pdf/1510.02037v2.pdf 7 شبكة البرق: https://lightning.network/lightningnetwork-paper-DRAFT-0.5.pdf 8 النعناع: https://github.com/tendermint/tendermint/wiki 9 استحالة FLP: https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf 10 المشرح: https://blog.ethereum.org/2014/01/15/slasher-apunitive-proof-of-stake-algorithm/ 11 فBFT: http://pmg.csail.mit.edu/papers/osdi99.pdf 12 بت: https://bitshares.org/technology/delegatedproof-of-stake-consensus/
13 Stellar: https://www.stellar.org/papers/stellar-consensusprotocol.pdf 14 دفتر الأستاذ: https://interledger.org/rfcs/0001-interledgerarchitecture/ 15 سلسلة جانبية: https://blockstream.com/sidechains.pdf 16 كاسبر: https://blog.ethereum.org/2015/08/01/introducing-casperfriendly-ghost/ 17 ABCI: https://github.com/tendermint/abci 18 Ethereum المشاركة: https://github.com/ethereum/EIPs/issues/53 19 ليب سويفت: http://www.ds.ewi.tudelft.nl/yleadmin/pds/papers/Performa nceAnalysOfLibswift.pdf 20 دي إل إس: http://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf 21 أمان العميل الرقيق: https://en.bitcoin.it/wiki/Thin_Client_Security 22 Ethereum 2.0 ورق بنفسجي: http://vitalik.ca/yles/mauve_paper.html https://www.docdroid.net/ec7xGzs/314477721-ethereumplatform-review-opportunities-and-challenges-for-privateand-consortium-blockchains.pdf.html
Ó ه