Cosmos: Dağıtılmış Defterlerden Oluşan Bir Ağ
介绍
开源生态系统的共同成功, 去中心化的yle共享,公共加密货币已经 激发了人们对去中心化互联网协议的理解 可用于从根本上改善社会经济基础设施。 我们已经看到了专门的 blockchain 应用程序,例如 Bitcoin [1] ( 加密货币)、Zerocash [2](一种保护隐私的加密货币)以及 通用 smart contract 平台,例如 Ethereum [3], 以太坊虚拟的无数分布式应用程序 机器(EVM),例如 Augur(预测市场)和 TheDAO [4](投资俱乐部)。 然而,迄今为止,这些 blockchain 已经遭受了许多问题的困扰。 的缺点,包括其总体能源效率低下、贫穷或 绩效有限,治理机制不成熟。 扩大 Bitcoin 交易吞吐量的建议,例如 隔离见证 [5] 和 BitcoinNG [6],是垂直缩放 解决方案仍然受到单个物理容量的限制 机,以保证性能的完全可审核性。 闪电网络 [7] 可以帮助扩展 Bitcoin 交易
通过将一些交易完全从分类账中删除来增加交易量, 非常适合小额支付和隐私保护 支付轨道,但可能不适合更普遍的情况 扩展需求。 理想的解决方案是允许多个并行 blockchain 互操作,同时保留其安全属性。这有 事实证明,对于 proof-of-work 来说,即使不是不可能,也是很困难的。合并 例如,采矿可以确保父母的安全 链可以在子链上重用,但交易仍然必须 按顺序由每个节点进行验证,并合并挖掘 blockchain 如果 hashing 上的大部分功率都容易受到攻击 父级没有积极地对子级进行合并挖掘。学术评论 提供了替代的 blockchain 网络架构 其他背景,我们提供其他提案的摘要 以及它们在相关工作中的缺点。 在这里,我们介绍 Cosmos,一种新颖的 blockchain 网络架构 解决所有这些问题。 Cosmos 是一个由许多人组成的网络 独立的 blockchain,称为区域。这些区域的动力来自 Tendermint Core [8],提供高性能、 一致、安全的类似 PBFT 的共识引擎,其中严格的责任保证可以抑制恶意行为 演员。 Tendermint Core 的 BFT 共识算法非常适合 用于缩放 public proof-of-stake blockchains。 Cosmos 上的第一个区域称为 Cosmos 中心。 Cosmos Hub 是一种多资产 proof-of-stake 加密货币,具有简单的 使网络能够适应和适应的治理机制 升级。此外,Cosmos 集线器可以通过以下方式扩展: 连接其他区域。 Cosmos 网络的集线器和区域与 彼此通过 blockchain 间通信 (IBC) 协议, blockchains 的一种虚拟 UDP 或 TCP。代币可以是 安全、快速地从一个区域转移到另一个区域无需在区域之间交换流动性。相反, 所有区域间 token 传输均通过 Cosmos 中心,该中心 跟踪每个区域持有的 token 总量。的 集线器将每个区域与其他区域的故障隔离开来。因为 任何人都可以将新区域连接到 Cosmos 集线器,区域允许 为了与新的 blockchain 创新未来兼容。 在本节中,我们将描述 Tendermint 共识协议 以及用于构建应用程序的接口。了解更多 详情见附录。 在经典拜占庭容错 (BFT) 算法中,每个节点 具有相同的重量。在 Tendermint 中,节点具有非负数 投票权的大小以及投票赞成的节点 电源称为 validators。验证者参与 通过广播加密签名达成共识协议,或者 投票,就下一个区块达成一致。 验证者的投票权是在创世时决定的,或者是 由 blockchain 确定性地更改,具体取决于 应用程序。例如,在 proof-of-stake 应用程序中,例如 Cosmos Hub,投票权可以由 作为抵押品的 staking token 数量。 注:像 ⅔ 和 ⅓ 这样的分数是指总投票数的分数 功率,绝不是 validator 的总数,除非所有 validator 都 具有相同的权重。 >⅔表示“超过⅔”,≥⅓表示“至少 ⅓”。 Tendermint 是一个部分同步的 BFT 共识协议 源自 DLS 共识算法 [20]。嫩薄荷是
以其简单性、性能和分叉责任而闻名。 该协议需要一组已知的 validator,其中每个 validator 由其公钥识别。验证者试图 一次就一个区块达成共识,其中一个区块就是一个列表 的交易。对区块进行投票以达成共识 回合。每轮都有一位轮次领导者或提议者,他们 提出一个区块。然后 validator 分阶段投票决定是否 接受提议的区块或进入下一轮。的 一轮的提议者是从有序的中确定性地选择的 validator 列表,按其投票权比例。 此处描述了该协议的完整细节。 Tendermint 的安全性源自其对最佳拜占庭式的使用 通过绝对多数 (>⅔) 投票和锁定实现容错 机制。他们共同确保: ≥⅓ 投票权必须是拜占庭式的才会导致违反 安全,承诺两个以上的价值观。 如果任何一组 validator 曾经成功违反安全性,甚至 尝试这样做时,它们可以被协议识别。这个 包括对冲突区块的投票和广播 不公正的选票。 尽管有强有力的保证,Tendermint 仍提供卓越的服务 性能。在分布在 7 个节点的 64 个节点的基准测试中 数据中心遍布五大洲,位于商品云实例上, Tendermint 共识可以处理数千笔交易 其次,提交延迟约为一到两秒。 值得注意的是,每笔交易的性能远远超过一千笔 即使在恶劣的对抗条件下,第二个也能保持, validators 崩溃或广播恶意制作的投票。参见 详情请参见下图。

Tendermint 共识算法的一个主要好处是简化 轻客户端安全性,使其成为移动和 物联网用例。虽然 Bitcoin 轻客户端必须同步 区块头链,并找到拥有最多证明的区块头链 工作,Tendermint 轻客户端只需要跟上变化 到 validator 集,然后验证 >⅔ PreCommits 最新块来确定最新状态。 简洁的轻客户端证明还可以实现blockchain之间的交互 沟通。 Tendermint 有保护措施来防止某些 值得注意的攻击,例如远程无利害关系双花 和审查制度。这些在附录中进行了更全面的讨论。Tendermint 共识算法是在 名为 Tendermint Core 的程序。 Tendermint 核心是 与应用程序无关的“共识引擎”,可以改变任何 将确定性黑盒应用程序转化为分布式复制 blockchain。 Tendermint Core 连接到 blockchain 应用程序 通过应用程序区块链接口 (ABCI) [17]。因此,ABCI 允许 blockchain 应用程序在任何 语言,而不仅仅是达成共识的编程语言 引擎被写入。此外,ABCI 可以轻松地 交换任何现有 blockchain 堆栈的共识层。 我们用著名的加密货币Bitcoin进行类比。 Bitcoin 是每个节点维护的加密货币 blockchain 经过全面审核的未花费交易输出 (UTXO) 数据库。如果 有人想在 ABCI 之上创建一个类似 Bitcoin 的系统, Tendermint Core 将负责 节点之间共享区块和交易 建立规范/不可变的交易顺序( blockchain) 同时,ABCI 应用程序将负责 维护 UTXO 数据库 验证交易的加密签名 防止交易花费不存在的资金 允许客户端查询 UTXO 数据库 Tendermint 能够通过以下方式分解 blockchain 设计: 在应用程序进程和 共识过程。
giriiş
Açık kaynak ekosisteminin birleşik başarısı, merkezi olmayan yle paylaşımı ve halka açık kripto para birimleri merkezi olmayan internet protokollerinin olduğu anlayışına ilham verdi Sosyo-ekonomik altyapının radikal bir şekilde iyileştirilmesi için kullanılabilir. Bitcoin [1] gibi özel blockchain uygulamalar gördük (a kripto para birimi), Zerocash [2] (gizlilik için bir kripto para birimi) ve Ethereum [3] gibi genelleştirilmiş smart contract platformları, Etherium Virtual için sayısız dağıtılmış uygulama Augur (tahmin piyasası) ve TheDAO gibi makine (EVM) [4] (bir yatırım kulübü). Ancak bugüne kadar bu blockchain'lar çok sayıda sorunla karşı karşıya kaldı Brüt enerji verimsizliği, zayıf veya sınırlı performans ve olgunlaşmamış yönetişim mekanizmaları. Bitcoin adlı kişinin işlem hacmini ölçeklendirmeye yönelik teklifler, örneğin Ayrılmış Tanık [5] ve BitcoinNG [6], dikey ölçeklendirmedir tek bir fiziksel kapasiteyle sınırlı kalan çözümler Tam denetlenebilirlik özelliğini sağlamak için makine. Lightning Network [7], Bitcoin işleminin ölçeklendirilmesine yardımcı olabilir
bazı işlemleri defterin tamamen dışında bırakarak hacim, ve mikro ödemeler ve gizliliğin korunması için çok uygundur ödeme rayları, ancak daha genelleştirilmiş ödeme rayları için uygun olmayabilir ölçeklendirme ihtiyaçları. İdeal bir çözüm, birden fazla paralel blockchain'nin birbirine bağlanmasına izin veren çözümdür. güvenlik özelliklerini korurken birlikte çalışabilirler. Bu var proof-of-work ile imkansız olmasa da zor olduğu kanıtlanmıştır. Birleştirilmiş örneğin madencilik, bir ebeveynin güvenliğini sağlamak için yapılan işin yapılmasına olanak tanır zincirin bir alt zincirde yeniden kullanılması gerekir, ancak işlemlerin yine de olması gerekir sırasıyla her düğüm tarafından doğrulanır ve birleştirme madenciliği yapılır blockchain hashing gücünün çoğunluğunun üzerinde olması durumunda saldırıya karşı savunmasızdır ebeveyn çocuğu aktif olarak birleştirme madenciliği yapmıyor. Akademik bir inceleme alternatif blockchain ağ mimarilerinin sayısı sağlanmıştır ek bağlam ve diğer tekliflerin özetlerini sunuyoruz ve İlgili Çalışmalardaki dezavantajları. Burada yeni bir blockchain ağ mimarisi olan Cosmos'yi sunuyoruz bu, tüm bu sorunları giderir. Cosmos birçok kişiden oluşan bir ağdır bağımsız blockchain'ler, bölgeler olarak adlandırılır. Bölgeler tarafından desteklenmektedir Yüksek performans sağlayan Tendermint Core [8], tutarlı, güvenli PBFT benzeri konsensüs motoru; burada kötü niyetli davranışların kontrol altında tutulması için katı bir hesap verebilirlik garanti edilir aktörler. Tendermint Core'un BFT fikir birliği algoritması çok uygundur genel proof-of-stake blockchains'yi ölçeklendirmek için. Cosmos üzerindeki ilk bölgeye Cosmos Hub adı verilir. Cosmos Hub, basit bir yapıya sahip çok varlıklı bir proof-of-stake kripto para birimidir. Ağın uyum sağlamasını ve uyum sağlamasını sağlayan yönetişim mekanizması yükseltme. Ayrıca Cosmos Hub şu kadar genişletilebilir: diğer bölgeleri birbirine bağlamak. Cosmos ağının hub'ları ve bölgeleri aşağıdakilerle iletişim kurar: blockchain arası iletişim (IBC) protokolü aracılığıyla birbirlerine, blockchains için bir tür sanal UDP veya TCP. Jetonlar olabilir bir bölgeden diğerine güvenli ve hızlı bir şekilde aktarılırbölgeler arasında döviz likiditesine ihtiyaç duymadan. Bunun yerine, tüm bölgeler arası token aktarımlar Cosmos Hub'dan geçer; her bölgenin tuttuğu toplam tokens miktarını takip eder. hub, her bölgeyi diğer bölgelerin arızasından izole eder. Çünkü herkes Cosmos Hub'a yeni bir bölge bağlayabilir, bölgeler buna izin verir yeni blockchain yeniliklerle geleceğe yönelik uyumluluk için. Bu bölümde Tendermint konsensüs protokolünü açıklıyoruz ve onunla uygulamalar oluşturmak için kullanılan arayüz. Daha fazlası için ayrıntılar için eke bakın. Klasik Bizans hataya dayanıklı (BFT) algoritmalarında her düğüm aynı ağırlığa sahiptir. Tendermint'te düğümlerin negatif olmayan bir değeri vardır. oylama gücü miktarı ve olumlu oy kullanan düğümler güçlere validators denir. Doğrulayıcılar katılıyor kriptografik imzalar yayınlayarak fikir birliği protokolü veya bir sonraki blok üzerinde anlaşmaya varmak için oy kullandı. Doğrulayıcıların oy verme yetkileri başlangıçta belirlenir veya bağlı olarak blockchain tarafından deterministik olarak değiştirildi uygulama. Örneğin, aşağıdaki gibi bir proof-of-stake uygulamasında Cosmos Merkezde, oylama gücü şu şekilde belirlenebilir: staking tokens miktarı teminat olarak teminat altına alındı. NOT: ⅔ ve ⅓ gibi kesirler toplam oyların kesirlerini ifade eder güç, tüm validator'ler olmadıkça asla validator'lerin toplam sayısı eşit ağırlığa sahip. >⅔ “⅔'den fazla”, ≥⅓ “en az” anlamına gelir ⅓”. Tendermint kısmen senkronize bir BFT konsensüs protokolüdür DLS konsensüs algoritmasından türetilmiştir [20]. Nane:
basitliği, performansı ve çatal sorumluluğuyla dikkat çekiyor. Protokol, yxed bilinen bir validator kümesi gerektirir; burada her biri validator ortak anahtarıyla tanımlanır. Doğrulayıcılar şunları yapmaya çalışır: Bir bloğun bir liste olduğu her seferinde bir blok üzerinde fikir birliğine varmak işlemler. Blok üzerinde fikir birliği için oylama sürüyor mermi. Her turun bir tur lideri veya teklif sahibi vardır. bir blok öneriyor. validator'ler daha sonra aşamalı olarak oy verirler. Önerilen bloğu kabul etmek veya bir sonraki tura geçmek için. Bir tur için öneride bulunan kişi, sıralananlar arasından deterministik olarak seçilir. oylama güçleriyle orantılı olarak validator'lerin listesi. Protokolün tüm ayrıntıları burada açıklanmaktadır. Tendermint'in güvenliği optimal Bizans kullanımından kaynaklanmaktadır. Süper çoğunluk (>⅔) oylama ve kilitleme yoluyla hata toleransı mekanizma. Birlikte şunları sağlarlar: ≥⅓ ihlale neden olabilmesi için oylama gücünün Bizans olması gerekir ikiden fazla değerin taahhüt edildiği güvenlik. herhangi bir validator kümesi güvenliği ihlal etmeyi başarırsa veya hatta bunu yapmaya kalkışırlarsa protokol tarafından tanımlanabilirler. Bu hem blokların birleştirilmesi hem de yayın için oylamayı içerir haksız oylar Güçlü garantilerine rağmen Tendermint olağanüstü çözümler sunuyor performans. 7'ye dağıtılmış 64 düğümden oluşan kıyaslamalarda 5 kıtadaki veri merkezleri, emtia bulutu örnekleri, Tendermint konsensüs başına binlerce işlemi işleyebilir ikincisi, bir ila iki saniyelik taahhüt gecikmeleriyle. Özellikle, başına binin üzerinde işlem performansı ikincisi zorlu düşmanlık koşullarında bile korunur; validators çöküyor veya kötü niyetle hazırlanmış oylar yayınlıyor. Bkz. ayrıntılar için aşağıdaki resme bakın.

Tendermint'in fikir birliği algoritmasının önemli bir avantajı basitleştirilmiştir hafif istemci güvenliği, onu mobil ve mobil cihazlar için ideal bir aday haline getiriyor Nesnelerin interneti kullanım örnekleri. Bitcoin hafif istemcinin senkronize edilmesi gerekirken blok başlık zincirleri ve en fazla kanıta sahip olanı bulun Tendermint hafif istemcilerinin yalnızca değişikliklere ayak uydurması gerekir validator kümesine gidin ve ardından >⅔ Ön Taahhütleri doğrulayın. En son durumu belirlemek için en son blok. Kısa ve öz hafif istemci provaları aynı zamanda inter-blockchain'yi de etkinleştirir iletişim. Tendermint'in belirli durumları önlemek için koruyucu önlemleri vardır. Uzun menzilli, tehlikede olmayan çifte harcamalar gibi dikkate değer saldırılar ve sansür. Bunlar ekte daha ayrıntılı olarak tartışılmaktadır.Tendermint fikir birliği algoritması, Tendermint Core adlı program. Tendermint Core bir herhangi bir şeyi dönüştürebilen, uygulamadan bağımsız “fikir birliği motoru” deterministik kara kutu uygulamasını dağıtılmış olarak çoğaltılmış bir uygulamaya dönüştürün blockchain. Tendermint Core blockchain uygulamaya bağlanır Uygulama Blok Zinciri Arayüzü aracılığıyla (ABCI) [17]. Böylece, ABCI blockchain uygulamaların herhangi bir biçimde programlanmasına olanak tanır dil, yalnızca fikir birliğine varılan programlama dili değil motora yazılmıştır. Ek olarak ABCI bunu kolayca mümkün kılar mevcut herhangi bir blockchain yığınının fikir birliği katmanını değiştirin. Tanınmış kripto para birimi Bitcoin ile bir benzetme yapıyoruz. Bitcoin her düğümün koruduğu bir blockchain kripto para birimidir tamamen denetlenmiş Harcanmamış İşlem Çıkışı (UTXO) veritabanı. Eğer ABCI üzerine Bitcoin benzeri bir sistem oluşturmak isteniyordu, Tendermint Core şunlardan sorumlu olacak: Düğümler arasında blokları ve işlemleri paylaşma Kanonik/değişmez bir işlem sırası oluşturmak ( blockchain) Bu arada, ABCI uygulaması şunlardan sorumlu olacaktır: UTXO veritabanının bakımı İşlemlerin kriptografik imzalarını doğrulama İşlemlerin var olmayan fonları harcamasını önleme İstemcilerin UTXO veritabanını sorgulamasına izin veriliyor Tendermint, blockchain tasarımını şu şekilde ayrıştırabilir: başvuru süreci arasında çok basit bir API sunuyor ve fikir birliği süreci.
Cosmos 架构
Cosmos 是一个独立并行 blockchain 的网络,它们是 每个都由经典的 BFT 共识算法提供支持,例如 嫩薄荷 1. 该网络中的第一个 blockchain 将是 Cosmos 中心。的 Cosmos 集线器通过一个连接到许多其他 blockchain(或区域) 新颖的blockchain间通信协议。 Cosmos 中心 跟踪众多 token 类型并记录总数 每个连接区域中的 token 数量。代币可以是 安全、快速地从一个区域转移到另一个区域 无需在区域之间进行液体交换,因为所有 区域间硬币转账通过 Cosmos 中心。 该架构解决了 blockchain 空间的许多问题 今天面临的问题,例如应用程序互操作性、可扩展性和 无缝升级能力。例如,从 Bitcoind 派生的区域, Go-Ethereum、CryptoNote、ZCash 或任何 blockchain 系统都可以 插入 Cosmos 集线器。这些区域允许 Cosmos 无限扩展以满足全球交易需求。区域还有 对于分布式交换来说,这是一个很棒的 yt,它将得到以下支持: 好吧。 Cosmos 不仅仅是一个分布式账本,而且 Cosmos Hub 不是一个有围墙的花园,也不是宇宙的中心。我们是 为分布式账本的开放网络设计协议 可以作为未来金融系统的新基础, 基于密码学原理、健全的经济学、共识 理论、透明度和问责制。 Cosmos 中心是 Cosmos 中的第一个公共 blockchain 网络,由 Tendermint 的 BFT 共识算法提供支持。的 Tendermint 开源项目诞生于 2014 年,旨在解决 Bitcoin 的工作量证明共识算法的速度、可扩展性和环境问题。通过使用和改进经过验证的
BFT 于 1988 年在 MIT 开发的算法 [20],Tendermint 团队是第一个概念性地演示 proof-of-stake 解决无利害关系问题的加密货币 遭受第一代 proof-of-stake 加密货币的困扰,例如 如 NXT 和 BitShares1.0。 如今,几乎所有 Bitcoin 移动钱包都使用可信服务器来 为他们提供交易验证。这是因为工作量证明需要在执行之前等待许多确认。 事务可以被视为不可逆转地提交。双花攻击已经在诸如 币库。 与其他 blockchain 共识系统不同,Tendermint 提供 即时且可证明安全的移动客户端支付验证。 由于 Tendermint 被设计为根本不会分叉,因此移动 钱包可以接收即时交易确认,这使得 无需信任且实用的支付在智能手机上成为现实。这个 对物联网应用具有重大影响,如 好吧。 Cosmos 中的验证者与 Bitcoin 矿工具有类似的角色,但是 而是使用加密签名进行投票。验证器是 负责提交的安全、专用机器 块。非 validator 可以委托其 staking token(称为 “atoms”)到任何 validator 以赚取部分区块费用和atom 奖励,但如果 委托 validator 被黑客攻击或违反协议。经证实的 Tendermint BFT 共识的安全保证以及抵押品 利益相关者的押金 –validators 和委托人 – 提供 节点和轻客户端的可证明、可量化的安全性。 分布式公共账本应该有一个章程和一个 治理体系。 Bitcoin 依赖于 Bitcoin 基金会并且挖矿来协调升级,但这是一个缓慢的过程。 Ethereum 硬分叉后分裂为 ETH 和 ETC 以解决 DAO 黑客攻击,很大程度上是因为没有事先的社会契约 也没有做出此类决定的机制。 Cosmos Hub 上的验证者和委托者可以投票 可以更改系统预设参数的建议 自动(例如区块gas limit),坐标升级,如 并对人类可读的宪法修正案进行投票 管理 Cosmos 中心的政策。宪法 允许利益相关者在以下问题上保持凝聚力: 盗窃和错误(例如TheDAO事件),允许更快和 更清晰的分辨率。 每个区域也可以有自己的宪法和治理 机制也是如此。例如,Cosmos 集线器可能有一个 强制中心不变性的宪法(无回滚, 保存 Cosmos Hub 节点实现的错误),同时 每个区域都可以设置自己的回滚策略。 通过实现不同政策区域之间的互操作性, Cosmos 网络为其用户提供最终的自由和潜力 未经许可的实验。 在这里,我们描述了一种去中心化和可扩展性的新颖模型。 Cosmos 是一个由许多 blockchain 组成的网络,由 嫩薄荷。虽然现有提案旨在创建“单一 blockchain”,全局交易排序总额为 Cosmos 允许许多 blockchain 彼此同时运行 同时保留互操作性。 在此基础上,Cosmos Hub 管理着许多独立的 blockchain 称为“区域”(有时称为“分片”,在 参考称为“分片”的数据库扩展技术)。
来自发布的区域的最近块提交的持续流 Hub 允许 Hub 跟上每个区域的状态。 同样,每个区域都与集线器的状态保持同步(但区域 除非间接通过 枢纽)。然后,信息包从一个 通过发布默克尔证明作为证据,将区域转移到另一个区域 信息已发送和接收。这种机制被称为 blockchain 间通信,简称 IBC。 任何区域本身都可以成为形成非循环图的中心, 但为了清楚起见,我们只描述简单的 只有一个集线器和许多非集线器的配置 区。 Cosmos 中心是托管多资产的 blockchain 分布式账本,其中 token 可以由个人用户持有或 由区域本身。这些 token 可以从一个区域移动 到另一个特殊的 IBC 数据包中,称为“硬币数据包”。枢纽是 负责保持总的全局不变性 跨区域的每个 token 的数量。 IBC 硬币包 交易必须由发送者、集线器和接收者提交 blockchains。由于 Cosmos Hub 充当整个系统的中央分类账 系统中,Hub 的安全至关重要。同时 每个区域都可以是 Tendermint blockchain,由 as 保护 少至 4 个(如果不需要 BFT 共识,甚至更少),Hub 必须由一组全球分散的 validator 来保证安全 可以承受最严重的攻击场景,例如 大陆网络分区或民族国家发起的攻击。 Cosmos 区域是一个独立的 blockchain,可交换 IBC 与 Hub 的消息。从 Hub 的角度来看,一个区域就是一个 多资产动态会员多重签名账户 可以使用 IBC 数据包发送和接收 tokens。就像一个 加密货币账户,一个区域不能传输超过 tokens 它有,但可以从拥有它们的其他人那里接收 token。 A区 可以被指定为一种或多种 token 类型的“源”, 授予其启动 token 电源的权力。 Cosmos 中心的原子可以由区域的 validator 质押 连接到集线器。虽然对这些区域进行双花攻击 将导致 Tendermint 的 forkaccountability 中的原子被削减,在该区域中,>⅔ 的投票权是 拜占庭可以提交无效状态。 Cosmos 集线器不 验证或执行在其他区域提交的交易,因此 用户有责任将 token 发送到他们信任的区域。 未来Cosmos Hub的治理体系可能会通过Hub 解决区域故障的改进建议。对于 例如,从某些(或所有)区域出站 token 传输可能会 被限制以允许区域紧急断路 (暂时停止 token 传输)当检测到攻击时。 现在我们看看中心和区域如何相互通信 其他。例如,如果有三个blockchain,“Zone1”,“Zone2”,

和“Hub”,我们希望“Zone1”生成一个数据包 “Zone2”穿过“Hub”。从一个数据包中移动一个数据包 blockchain 到另一个,一个证明被发布在接收链上。 该证明表明发送链发布了一个数据包 所谓的目的地。为了让接收链检查这个证明,它 必须能够跟上发送者的块头。这个 机制与侧链使用的机制类似,需要 两个相互作用的链通过 存在性数据报的双向流 (交易)。 IBC 协议自然可以使用两种类型来定义 交易:一个 IBCBlockCommitTx 交易,它允许 blockchain 向任何观察者证明其最新区块-hash, 和一个 IBCPacketTx 交易,它允许 blockchain 向任何观察者证明给定的数据包确实已发布 通过发送者的应用程序,通过对最近的 Merkle 证明 块-hash。 通过将 IBC 机制拆分为两个单独的事务,我们 允许接收链的原生费用市场机制 确定哪些数据包被提交(即确认),同时 允许发送链上完全自由地决定如何 允许许多出站数据包。 上例中,为了更新“Zone1”的块-hash 在“Hub”(或“Zone2”上的“Hub”)上,一个 IBCBlockCommitTx交易必须发布在“Hub”上,区块为hash “Zone1”(或在“Zone2”上,具有“Hub”的块hash)。 有关更多信息,请参阅 IBCBlockCommitTx 和 IBCPacketTx 关于两种 IBC 交易类型。 同样,Bitcoin 通过分布式更安全, 大规模复制的账本,我们可以使交易所不易受到 通过在 blockchain 上运行它来进行外部和内部黑客攻击。我们 称之为分布式交换。 加密货币社区所谓的去中心化 今天的交易所基于所谓的“原子跨链”(AXC)交易。通过 AXC 交易,两个用户 两条不同的链可以进行两笔转账交易 在两个分类账上一起承诺,或者根本没有承诺(即 原子地)。例如,两个用户可以用比特币交换以太币(或 两个不同分类账上的任意两个 token)使用 AXC 交易, 即使 Bitcoin 和 Ethereum 没有连接到每个 其他。在 AXC 交易上运行交易所的好处是 用户不需要互相信任或交易匹配 服务。缺点是双方都需要在线 交易发生。 另一种类型的去中心化交易所是大规模复制的 自行运行的分布式交换 blockchain。用户在 这种交易所可以提交限价订单并将其转为 计算机关闭,无需用户操作即可执行交易 在线。 blockchain 代表匹配并完成交易 交易者的。
Cosmos Mimarlık
Cosmos bağımsız paralel blockchain'lerden oluşan bir ağdır ve bunlar her biri klasik BFT fikir birliği algoritmaları tarafından desteklenmektedir: İhale 1. Bu ağdaki ilk blockchain, Cosmos Hub olacaktır. Cosmos Hub, diğer birçok blockchains'ye (veya bölgeye) bir ağ aracılığıyla bağlanır. yeni inter-blockchain iletişim protokolü. Cosmos Merkezi çok sayıda token türünü izler ve toplamın kaydını tutar bağlı her bölgedeki tokens sayısı. Jetonlar olabilir bir bölgeden diğerine güvenli ve hızlı bir şekilde aktarılır bölgeler arasında sıvı değişimine gerek kalmadan, çünkü hepsi bölgeler arası para transferleri Cosmos Hub üzerinden yapılır. Bu mimari, blockchain alanının karşılaştığı birçok sorunu çözmektedir. Uygulamaların birlikte çalışabilirliği, ölçeklenebilirliği ve kesintisiz yükseltilebilirlik. Örneğin, Bitcoind'den türetilen bölgeler, Go-Ethereum, CryptoNote, ZCash veya herhangi bir blockchain sistemi şunları yapabilir: Cosmos Hub'a takılmalıdır. Bu bölgeler Cosmos'nin şunları yapmasına izin verir: Küresel işlem talebini karşılamak için sonsuz ölçeklenebilirlik. Bölgeler aynı zamanda olarak desteklenecek olan dağıtılmış bir değişim için harika bir yt peki. Cosmos yalnızca tek bir dağıtılmış defter değildir ve Cosmos Hub duvarlarla çevrili bir bahçe ya da evrenin merkezi değil. Biz dağıtılmış defterlerden oluşan açık bir ağ için bir protokol tasarlamak gelecekteki finansal sistemler için yeni bir temel görevi görebilecek, Kriptografi ilkelerine, sağlam ekonomiye, fikir birliğine dayalı teori, şeffaflık ve hesap verebilirlik. Cosmos Hub, Cosmos bölgesindeki ilk genel blockchain merkezidir. Ağ, Tendermint'in BFT fikir birliği algoritması tarafından desteklenmektedir. Tendermint açık kaynak projesi 2014 yılında bu sorunu çözmek için doğdu. Bitcoin'nin çalışma kanıtı fikir birliği algoritmasının hızı, ölçeklenebilirliği ve çevresel sorunları. Kanıtlanmış olanı kullanarak ve geliştirerek
BFT MIT'de 1988'de geliştirilen algoritmalar [20], Tendermint ekip kavramsal olarak proof-of-stake'yi sergileyen ilk ekip oldu tehlikede olmayan hiçbir şey sorununu çözen kripto para birimi ilk nesil proof-of-stake kripto para birimlerinin sıkıntısını çekti NXT ve BitShares1.0 olarak. Bugün neredeyse tüm Bitcoin mobil cüzdanlar güvenilir sunucuları kullanıyor. onlara işlem doğrulaması sağlayın. Bunun nedeni, iş kanıtının bir onaydan önce birçok onayın beklenmesini gerektirmesidir. işlemin geri dönülemez şekilde taahhüt edildiği kabul edilebilir. Doublespend saldırıları halihazırda aşağıdaki gibi hizmetlerde gösterilmiştir: CoinBase. Diğer blockchain fikir birliği sistemlerinden farklı olarak Tendermint şunları sunar: anında ve kanıtlanabilir şekilde güvenli mobil müşteri ödeme doğrulaması. Tendermint hiçbir zaman çatallanmayacak şekilde tasarlandığından, mobil cüzdanlar anında işlem onayı alabilir, bu da Güvenilir ve pratik ödemeler akıllı telefonlarda gerçek oluyor. Bu Nesnelerin İnterneti uygulamaları için önemli sonuçlar doğurmaktadır. peki. Cosmos içindeki doğrulayıcılar, Bitcoin madencilerine benzer bir role sahiptir, ancak bunun yerine oy vermek için kriptografik imzaları kullanın. Doğrulayıcılar taahhüt etmekten sorumlu güvenli, özel makineler bloklar. validator olmayanlar staking token'leri devredebilir (çağrılır) Blok ücretlerinin ve atomun bir kısmını kazanmak için herhangi bir validator'ye "atomlar") ödüller, ancak cezalandırılma (kesilme) riskiyle karşı karşıya kalırlar; validator numaralı delege saldırıya uğradı veya protokolü ihlal etti. Kanıtlanmış Tendermint BFT konsensusunun güvenlik garantileri ve teminatlar paydaşların depozitosu–validators ve delegeler–sağlar Düğümler ve hafif istemciler için kanıtlanabilir, ölçülebilir güvenlik. Dağıtılmış kamu defterlerinin bir anayasası ve yönetim sistemi. Bitcoin, Bitcoin Vakfına güveniyor veyükseltmeleri koordine etmek için madencilik yapın, ancak bu yavaş bir süreçtir. Ethereum, adrese zorlanmanın ardından ETH ve ETC'ye bölündü DAO hacklenmesinin nedeni büyük ölçüde önceden bir toplumsal sözleşmenin olmamasıydı ne de bu tür kararları almaya yönelik mekanizma. Cosmos Merkezindeki doğrulayıcılar ve yetki verenler oy verebilir sistemin önceden ayarlanmış parametrelerini değiştirebilecek öneriler otomatik olarak (blok gaz limiti gibi), yükseltmeleri koordine edin insanların okuyabileceği anayasada yapılacak değişikliklere oy vermek Cosmos Hub'ın politikalarını yöneten. Anayasa gibi konularda paydaşlar arasında uyum sağlar. hırsızlık ve hatalar (TheDAO olayı gibi), daha hızlı ve daha temiz çözünürlük. Her bölgenin kendi anayasası ve yönetimi de olabilir mekanizması da. Örneğin, Cosmos Hub'ın bir özelliği olabilir Merkezde değişmezliği zorunlu kılan anayasa (geri alma yok, Cosmos Hub düğümü uygulamasının hataları için tasarruf edin), her bölge geri alma işlemleriyle ilgili kendi politikalarını belirleyebilir. Farklı politika alanları arasında birlikte çalışabilirliği sağlayarak, Cosmos ağı, kullanıcılarına en üst düzeyde özgürlük ve potansiyel sunar. izinsiz deneme. Burada yeni bir ademi merkeziyet ve ölçeklenebilirlik modelini tanımlıyoruz. Cosmos, birçok blockchain'den oluşan bir ağdır. Nane. Mevcut teklifler “tek bir blockchain” toplam küresel işlem sıralamasıyla birlikte, Cosmos birçok blockchain'nin birbiriyle eşzamanlı çalışmasına izin verir birlikte çalışabilirliği korurken. Temelde Cosmos Hub birçok bağımsız yönetimi yönetiyor blockchains "bölgeler" olarak adlandırılır (bazen "parçalar" olarak da anılır), "parçalama" olarak bilinen veritabanı ölçeklendirme tekniğine referans.
Yayınlanan bölgelerden gelen son blok işlemlerinin sürekli akışı Hub, Hub'ın her bölgenin durumunu takip etmesine olanak tanır. Benzer şekilde, her bölge Hub'ın durumuna ayak uydurur (ancak bölgeler aracılığıyla dolaylı olarak birbirinizi takip etmeyin. Merkez). Bilgi paketleri daha sonra birinden iletilir. Merkle-kanıtlarını kanıt olarak yayınlayarak bölgeden diğerine geçin. Bilgiler gönderildi ve alındı. Bu mekanizmaya denir inter-blockchain iletişim veya kısaca IBC. Bölgelerden herhangi biri döngüsel olmayan bir grafik oluşturmak için merkez olabilir, ancak netlik sağlamak amacıyla yalnızca basit olanı tanımlayacağız. Yalnızca bir hub'ın ve birçok hub'ın olmadığı yapılandırma bölgeler. Cosmos Hub, çoklu varlıkları barındıran bir blockchain'dır token'lerin bireysel kullanıcılar tarafından tutulabileceği dağıtılmış defter veya bölgelerin kendileri tarafından. Bu token'ler bir bölgeden taşınabilir diğerine "bozuk para paketi" adı verilen özel bir IBC paketinde. Merkez toplamın küresel değişmezliğini korumaktan sorumludur bölgeler genelinde her token miktarı. IBC bozuk para paketi işlemler gönderen, hub ve alıcı tarafından gerçekleştirilmelidir blockchains.Cosmos Merkez, tüm hesap için merkezi defter görevi gördüğü için Sistemde Hub'ın güvenliği büyük önem taşımaktadır. iken her bölge şu şekilde güvence altına alınan bir Tendermint blockchain olabilir: 4 kadar az (veya BFT fikir birliğine ihtiyaç duyulmuyorsa daha da az), Hub küresel olarak merkezi olmayan bir validator kümesi tarafından güvence altına alınmalıdır; gibi en şiddetli saldırı senaryolarına dayanabilir. kıtasal ağ bölünmesi veya ulus devlet destekli bir saldırı. Cosmos bölgesi, IBC alışverişini yapan bağımsız bir blockchain bölgesidir Hub ile mesajlar. Merkezin bakış açısına göre bir bölge bir çok varlıklı dinamik üyelikli çoklu imza hesabı IBC paketleri kullanarak tokens gönderip alabilir. Bir gibi kripto para birimi hesabı, bir bölge şu sayıdan daha fazla tokens aktaramaz sahiptir, ancak bunlara sahip olan diğer kişilerden token alabilir. Bir bölge bir veya daha fazla token türünün "kaynağı" olarak belirtilebilir, ona token arzını doldurma gücü veriyor. Cosmos Hub'ın atomları bir bölgenin validator'leri tarafından desteklenebilir Hub'a bağlı. Bu bölgelere çift harcama saldırıları yapılırken oylama gücünün >⅔'ünün olduğu bir bölge olan Tendermint'in hesap verebilirliği ile atomların parçalanmasıyla sonuçlanacaktır Bizans geçersiz durumu taahhüt edebilir. Cosmos Hub çalışmıyor diğer bölgelerde gerçekleştirilen işlemleri doğrulayın veya yürütün; güvendikleri bölgelere token'ler gönderme sorumluluğu kullanıcıların sorumluluğundadır. Gelecekte Cosmos Hub'ın yönetim sistemi Hub'ı geçebilir Bölge arızalarını hesaba katan iyileştirme önerileri. için örneğin, bazı (veya tüm) bölgelerden giden token aktarımlar Bölgelerin acil devre kesilmesine izin vermek için kısılabilir (token aktarımların geçici olarak durdurulması) bir saldırı algılandığında. Şimdi Hub ve bölgelerin birbiriyle nasıl iletişim kurduğuna bakıyoruz diğer. Örneğin, üç adet blockchains varsa, "Bölge1", "Bölge2",

ve “Hub” ve "Bölge1"in hedeflenen bir paket üretmesini diliyoruz. “Hub”tan geçen “Bölge2” için. Bir paketi birinden taşımak için blockchain diğerine, alıcı zincirine bir kanıt gönderilir. Kanıt, gönderen zincirin bir paket yayınladığını belirtir. iddia edilen varış noktası Alıcı zincirin bu kanıtı kontrol etmesi için gönderenin blok başlıklarını takip edebilmelidir. Bu mekanizma, yan zincirler tarafından kullanılan mekanizmaya benzer; Birbiriyle etkileşim halinde olan iki zincirin birbirinden haberdar olması varoluş kanıtı datagramlarının çift yönlü akışı (işlemler). IBC protokolü doğal olarak iki tür kullanılarak tanımlanabilir. işlemler: izin veren bir IBCBlockCommitTx işlemi blockchain herhangi bir gözlemciye en son bloğunun hash olduğunu kanıtlamak için, ve bir IBCPacketTx işlemi; bu, blockchain işleminin yapılmasına olanak tanır. herhangi bir gözlemciye verilen paketin gerçekten yayınlandığını kanıtlayın gönderenin başvurusuyla, Merkle-kanıtı aracılığıyla en son blok-hash. IBC mekaniğini iki ayrı işleme bölerek, Alıcı zincirin yerel ücret piyasası mekanizmasının hangi paketlerin işleneceğini (yani onaylanacağını) belirlerken, Gönderim zincirinde bunun nasıl yapılacağı konusunda tam bir özgürlük sağlanması birçok giden pakete izin verilir. Yukarıdaki örnekte, "Zone1"in-hash bloğunu güncellemek için “Hub”da (veya “Zone2”deki “Hub”da), bir IBCBlockCommitTxişlem “Hub” üzerinde hash bloğuyla yayınlanmalıdır. “Bölge1” (veya “Hub”ın hash bloğuyla "Bölge2" üzerinde). Daha fazla bilgi için IBCBlockCommitTx ve IBCPacketTx'e bakın. iki IBC işlem türünde. Aynı şekilde Bitcoin dağıtılmış olduğundan daha güvenlidir, toplu kopyalanmış defter sayesinde borsaları daha az savunmasız hale getirebiliriz blockchain üzerinde çalıştırarak harici ve dahili saldırıları gerçekleştirebilirsiniz. Biz buna dağıtılmış değişim diyoruz. Kripto para topluluğunun merkezi olmayan yapı olarak adlandırdığı şey Bugünkü borsalar “atomik çapraz zincir” (AXC) işlemleri adı verilen bir şeye dayanıyor. Bir AXC işlemiyle iki kullanıcı iki farklı zincir iki transfer işlemi yapabilir her iki defterde birlikte işlenir veya hiç yapılmaz (ör. atomik olarak). Örneğin, iki kullanıcı bitcoinleri eterle takas edebilir (veya AXC işlemlerini kullanarak iki farklı defterdeki herhangi iki tokens, Bitcoin ve Ethereum her birine bağlı olmasa da diğer. AXC işlemlerinde borsa çalıştırmanın faydası kullanıcıların birbirlerine veya ticari eşleştirmeye güvenmesine gerek yok hizmet. Dezavantajı ise her iki tarafın da çevrimiçi olması gerekmesidir. gerçekleşecek olan ticarettir. Merkezi olmayan değişimin bir başka türü de kitlesel olarak kopyalanan borsalardır. kendi başına çalışan dağıtılmış borsa blockchain. Kullanıcılar bu tür borsalar limit emri verebilir ve emirlerini çevirebilirler. bilgisayar kapalıdır ve işlem kullanıcı olmadan yürütülebilir çevrimiçi. blockchain eşleşir ve takası onun adına tamamlar tüccarın.
应用领域
中心化交易所可以创建深度限价订单簿 订单,从而吸引更多的交易者。流动性产生更多 交易所世界的流动性,因此有强大的网络 交换中的效应(或至少是赢家通吃的效应) 业务。当今加密货币交易所的当前领导者 Poloniex 的 24 小时交易量为 2000 万美元,位居第二的是 Bitynex 24 小时交易量为 500 万美元。鉴于如此强大的网络 影响,基于 AXC 的去中心化交易所不太可能 赢得中心化交易所的交易量。对于去中心化的 交易所要与中心化交易所竞争,需要 支持带有限价订单的深度订单簿。只有一个分布式 blockchain 上的交换可以提供这一点。 Tendermint 提供更快交易的额外好处 承诺。通过优先考虑快速性而不牺牲 一致性,Cosmos 中的区域可以快速分析事务 – 用于 交换订单交易以及 IBC token 转账至 以及来自其他区域的。 鉴于当今加密货币交易所的状况,一个伟大的 Cosmos 的应用程序是分布式交换(又名 Cosmos DEX)。交易吞吐能力以及 提交延迟可以与集中式的延迟相媲美 交流。交易者可以提交可以执行的限价订单 无需双方都在线。和 Tendermint 一起, 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 一侧( 起源),桥接合约将允许以太币持有者发送以太币 通过将其发送到桥接合约来发送到桥接区 Ethereum。一旦桥接合约收到以太币, 除非有适当的 IBC 数据包,否则无法提取以太币 由桥接合同从桥接区接收。的 桥接合约跟踪桥接区域的 validator 集,其中 可能与 Cosmos 集线器的 validator 集相同。 在 Bitcoin 的情况下,概念类似,只不过不是 一个桥梁合约,每个 UTXO 将由 阈值多重签名 P2SH pubscript。由于限制 P2SH 系统中,签名者不能与 Cosmos 相同 轮毂 validator-套。桥接区域上的以太币(“桥接以太币”)可以转移到 并从中心,然后通过交易销毁 将其发送到 Ethereum 上的特定提款地址。 IBC 证明事务发生在桥接区域的数据包 可以发布到 Ethereum 桥接合约以允许以太币 被撤回。 在 Bitcoin 的情况下,受限脚本系统使其 很难反映 IBC 硬币转移机制。每个 UTXO 有自己独立的pubscript,因此每个 UTXO 必须是 当集合发生变化时迁移到新的 UTXO Bitcoin 托管签名者。一种解决方案是压缩并 根据需要解压 UTXO-set 以保留总数 UTXO 秒下降。 这种桥接合约的风险是流氓 validator 集。 ≥⅓ 拜占庭投票权可能会导致分叉,提取以太币 来自 Ethereum 的桥接合约,同时将桥接以太币保持在桥接区域。更糟糕的是,>⅔ 拜占庭投票权可以 从发送到桥接合约的人那里直接窃取以太币 偏离了桥接区的原始桥接逻辑。 可以通过设计桥梁来解决这些问题 完全负责。例如,来自集线器的所有 IBC 数据包和 起源,可能需要桥接区的确认 这样桥区的所有状态转换都可以 受到枢纽或始发地的有效挑战和验证 过桥合同。中心和来源应允许桥区 validators 发布抵押品,并且 token 转出 过渡合同应该被推迟(并且抵押品解绑 足够长的时间)以允许提出任何挑战 独立审计师。我们留下规格的设计和 该系统的实施作为未来开放 Cosmos
改进提案,由 Cosmos 中心通过 治理体系。 解决缩放问题是 Ethereum 的一个悬而未决的问题。 目前,Ethereum 节点处理每笔交易并 还存储所有状态。关联。 由于 Tendermint 提交区块的速度比 Ethereum 快得多 proof-of-work、EVM 由 Tendermint 共识支持的区域和 在桥接以太网上运行可以提供更高的性能 Ethereum blockchains。此外,虽然 Cosmos 集线器和 IBC 数据包机制不允许任意合约逻辑 执行本身,它可用于协调 token 运动 在不同区域运行的 Ethereum 合约之间, 为以 token 为中心的 Ethereum 扩展提供基础 分片。 Cosmos 区域运行任意应用程序逻辑,其定义为 该区域生命的开始,并且有可能更新 随着时间的推移,通过治理。这种灵活性允许 Cosmos 区域 充当其他加密货币的桥梁,例如 Ethereum 或 Bitcoin,并且它还允许这些 blockchain 的衍生物, 使用相同的代码库但具有不同的 validator 集并且 初始分布。这使得许多现有的加密货币 框架,例如 Ethereum、Zerocash、Bitcoin 的框架, CryptoNote 等,与 Tendermint Core 一起使用, 在公共网络上更高性能的共识引擎, 为跨领域的互操作性提供了巨大的机会 平台。此外,作为多资产 blockchain,单一资产 交易可能包含多个输入和输出,其中每个 输入可以是任何 token 类型,使 Cosmos 能够直接用作 去中心化交易平台,但假设有订单通过其他平台进行匹配。或者,区域可以服务 作为分布式容错交易所(带有订单簿), 可以是对现有集中式的严格改进 随着时间的推移,加密货币交易所往往会遭到黑客攻击。 区域还可以用作 blockchain 支持的企业版本 和政府系统,其中特定服务的各个部分 传统上由一个组织或一组组织运营 相反,它们作为 ABCI 应用程序在某个区域上运行, 让它继承大众的安全性和互操作性 Cosmos 网络而不牺牲对底层的控制 服务。因此,Cosmos 可能会提供两全其美的方案: 希望利用 blockchain 技术但谁是的组织 警惕将控制权完全交给分布式第三方 聚会。 一些人声称,有利于一致性的一个主要问题是 像 Tendermint 这样的共识算法是任何网络 分区导致不存在 >⅔ 的单个分区 投票权(例如≥⅓)将完全停止共识。 Cosmos 架构可以通过使用来帮助缓解这个问题 拥有区域自治区的全球中心,拥有投票权 每个区域都根据共同的地理分布 地区。例如,一个共同的范式可能适用于个人 城市或地区在共享资源的同时运营自己的区域 公共中心(例如 Cosmos 中心),使市政活动能够 在集线器由于临时网络而停止的情况下继续存在 分区。请注意,这允许真实的地质、政治和 设计鲁棒性时要考虑的网络拓扑特征 联合容错系统。
NameCoin 是第一个尝试解决这个问题的 blockchain 之一 通过调整 Bitcoin blockchain 来解决名称解析问题。 不幸的是,这种方法存在几个问题。 通过 Namecoin,我们可以验证,例如,@satoshi 是 在过去的某个时刻使用特定的公钥注册, 但我们不知道公钥是否已经被 最近更新,除非我们下载自上次以来的所有块 该名称的更新。这是由于 Bitcoin 的限制 UTXO 交易默克尔化模型,其中只有 交易(但不是可变的应用程序状态)是 Merkle 化的 进入块-hash。这让我们可以证明名称的存在,但不能证明名称的后续更新不存在。因此,我们无法得知 确定名称的最新值而不信任完整的 节点,或者通过下载产生大量带宽成本 整个blockchain。 即使在 NameCoin 中实现了 Merkle 化的搜索树, 它对 proof-of-work 的依赖使得轻客户端验证 有问题的。轻客户端必须下载完整的副本 整个 blockchain 中所有块的标头(或者至少是所有 自上次更新名称以来的标题)。这意味着 带宽需求随时间量线性变化 [21]。此外,proof-of-work blockchain 上的名称更改 需要等待额外的 proof-of-work 确认块, Bitcoin 上最多可能需要一个小时。 对于 Tendermint,我们只需要最新的区块 -hash 由 validator 的法定人数(通过投票权)和 Merkle 签署 证明与该名称关联的当前值。这使得 可以拥有一个简洁、快速、安全的轻客户端 名称值的验证。 在Cosmos中,我们可以采用这个概念并进一步扩展它。每个 Cosmos 中的名称注册区域可以有一个关联的顶级域 (TLD) 名称,例如“.com”或“.org”,并且每个名称-
注册区可以有自己的治理和注册 规则。
Uygulamalar
Merkezi bir borsa, derin bir limit emir defteri oluşturabilir siparişler verir ve böylece daha fazla tüccar çeker. Likidite daha fazlasını doğurur Borsa dünyasında likidite ve dolayısıyla güçlü bir ağ var takasta etkisi (veya en azından kazananın çoğunu alması etkisi) iş. Bugünün kripto para borsalarının mevcut lideri Poloniex 24 saatlik hacimle 20 milyon dolar ile ikinci sırada yer alıyor. Bitynex'in 24 saatlik hacmi 5 milyon dolar. Bu kadar güçlü bir ağ göz önüne alındığında AXC tabanlı merkezi olmayan borsaların Merkezi borsalarda hacim kazanma. Merkezi olmayan bir sistem için Merkezi bir borsayla rekabet edebilmek için borsanın derin emir defterlerini limitli emirlerle desteklemek. Yalnızca dağıtılmış blockchain üzerindeki değişim bunu sağlayabilir. Tendermint, daha hızlı işlem yapmanın ek faydalarını sağlar taahhüt eder. Ödün vermeden hızlı üretime öncelik vererek tutarlılık sayesinde Cosmos içindeki bölgeler işlemleri hızlı bir şekilde analiz edebilir; hem takas emri işlemleri hem de IBC token transferleri ve diğer bölgelerden. Kripto para borsalarının bugünkü durumu göz önüne alındığında, büyük bir Cosmos başvurusu dağıtılmış borsadır (diğer adıyla Cosmos DEX). İşlem çıkış kapasitesi ve taahhüt gecikmesi merkezileştirilmiş olanlarla karşılaştırılabilir olabilir borsalar. Yatırımcılar gerçekleştirilebilecek limitli emirler gönderebilirler her iki tarafın da çevrimiçi olmasına gerek kalmadan. Ve Tendermint ile, Cosmos merkezi ve IBC ile yatırımcılar fonları içeri ve dışarı taşıyabilirler hızlı bir şekilde diğer bölgelere gidiş-dönüş alışverişi. Ayrıcalıklı bir bölge, köprülenmiş bir token kaynağı olarak hareket edebilir başka bir kripto para birimi. Köprü ilişkiye benzer Cosmos hub ve bölge arasında; her ikisi de buna ayak uydurmalı tokens'nin sahip olduğu kanıtları doğrulamak için diğerinin en son blokları birinden diğerine taşındı. Cosmos üzerinde bir "köprü bölgesi" ağ hem Hub'a hem de diğerine ayak uydurur
kripto para birimi. Köprü bölgesi üzerinden yönlendirme, Hub'ın mantığının basit kalması ve diğerlerine göre agnostik olması blockchain Bitcoin'nın proof-of-work gibi fikir birliği stratejileri madencilik. Her köprü bölgesi validator Tendermint destekli bir sistem çalıştıracaktır. blockchain özel bir ABCI köprü uygulamasına ve aynı zamanda tam düğüme sahip “köken” blockchain. Başlangıç noktasında yeni bloklar çıkarıldığında köprü bölgesi validators imzalayarak taahhüt edilen bloklar üzerinde anlaşmaya varacak ve kaynağın blockchain ile ilgili yerel görüşlerini paylaşıyorlar ipucu. Bir köprü bölgesi başlangıç noktasında ödeme aldığında (ve davada yeterli onayın görüldüğü konusunda anlaşmaya varıldı Ethereum veya Bitcoin gibi bir PoW zincirinin), karşılık gelen Bu bakiye ile köprü bölgesinde hesap oluşturulur. Ethereum durumunda köprü bölgesi aynısını paylaşabilir validator--Cosmos Hub olarak ayarlandı. Ethereum tarafında ( Origin), bir köprü sözleşmesi, Ether sahiplerinin Ether göndermesine izin verecek tarihinde köprü sözleşmesine göndererek köprü bölgesine Ethereum. Köprü sözleşmesiyle eter alındıktan sonra, Uygun bir IBC paketi sağlanmadıkça eter geri çekilemez köprü sözleşmesiyle köprü bölgesinden alındı. köprü sözleşmesi köprü bölgesinin validator kümesini izler; Cosmos Hub'ın validator-setiyle aynı olabilir. Bitcoin durumunda kavram benzerdir ancak bunun yerine tek bir köprü sözleşmesi, her UTXO bir kişi tarafından kontrol edilecektir. eşik çoklu imza P2SH yayını. Sınırlamalar nedeniyle P2SH sisteminde imzalayanlar Cosmos ile aynı olamaz Hub validator-set.Köprü bölgesindeki eter ("köprülü eter") şuraya aktarılabilir: ve Hub'dan ve daha sonra bir işlemle yok edilmesi Ethereum adresindeki belirli bir para çekme adresine gönderir. Bir IBC İşlemin köprü bölgesinde gerçekleştiğini kanıtlayan paket etere izin vermek için Ethereum köprü sözleşmesine gönderilebilir geri çekilmek. Bitcoin durumunda, kısıtlı komut dosyası sistemi bunu yapar IBC para transfer mekanizmasını yansıtmak zor. Her biri UTXO kendi bağımsız yayın metni vardır, dolayısıyla her UTXO kümesinde bir değişiklik olduğunda yeni bir UTXO'ye taşındı Bitcoin emanet imzalayanlar. Çözümlerden biri sıkıştırmak ve toplam sayıyı korumak için UTXO-setinin sıkıştırmasını gerektiği kadar açın UTXOs'den fazlası kapatıldı. Böyle bir köprüleme sözleşmesinin riski hileli bir validator kümesidir. ≥⅓ Bizans'ın oy verme gücü eterin çekilmesine neden olabilir Ethereum üzerindeki köprü sözleşmesinden, köprüyü köprü bölgesinde tutarken. Daha da kötüsü, Bizans'ın oylama gücü >⅔ Eteri köprü sözleşmesine gönderenlerden doğrudan çalmak köprü bölgesinin orijinal köprüleme mantığından saparak. Köprüyü uygun şekilde tasarlayarak bu sorunları çözmek mümkündür. tamamen sorumlu. Örneğin, hub'dan gelen tüm IBC paketleri ve menşei, köprü bölgesi tarafından onaylanmayı gerektirebilir öyle ki köprü bölgesinin tüm durum geçişleri merkez ya da menşe tarafından verimli bir şekilde sorgulanmış ve doğrulanmıştır köprü sözleşmesi. Hub ve menşe, validators köprü bölgesinin teminat göndermesine ve token'nin merkezden transfer yapmasına izin vermelidir. Köprü sözleşmesi ertelenmeli (ve teminatların çözülmesi yeterince uzun bir süre) herhangi bir zorluğun üstesinden gelinmesine izin vermek için bağımsız denetçiler. Şartnamenin tasarımını bırakıyoruz ve bu sistemin uygulanması gelecekte açık olacak Cosmos
iyileştirme teklifi, Cosmos Merkez tarafından onaylanacak yönetim sistemi. Ölçekleme sorununu çözmek Ethereum için açık bir konudur. Şu anda Ethereum düğüm her bir işlemi işliyor ve ayrıca tüm durumları saklar. bağlantı. Tendermint, blokları Ethereum'den çok daha hızlı işleyebildiğinden proof-of-work, EVM bölgeleri Tendermint konsensusu tarafından desteklenmektedir ve köprülü eter üzerinde çalışmak daha yüksek performans sağlayabilir Ethereum blockchains. Ayrıca, Cosmos Hub ve IBC paket mekaniği keyfi sözleşme mantığına izin vermez kendi başına yürütme, token hareketleri koordine etmek için kullanılabilir farklı bölgelerde çalışan Ethereum sözleşmeler arasında, token merkezli Ethereum ölçeklendirme için bir temel sağlar parçalama. Cosmos bölgeleri, şu saatte tanımlanan rastgele uygulama mantığını çalıştırır: bölgenin yaşamının başlangıcıdır ve potansiyel olarak güncellenebilir zamanla yönetim tarafından Bu esneklik, Cosmos bölgelerinin Ethereum gibi diğer kripto para birimlerine köprü görevi görür veya Bitcoin ve aynı zamanda bu blockchain'lerin türevlerine de izin verir, aynı kod tabanını kullanıyor ancak farklı bir validator kümesiyle ve ilk dağıtım. Bu, mevcut birçok kripto para biriminin Ethereum, Zerocash, Bitcoin gibi çerçeveler, Tendermint Core ile kullanılacak CryptoNote vb. ortak bir ağ üzerinde daha yüksek performanslı bir fikir birliği motoru, arasında birlikte çalışabilirlik için muazzam bir fırsat yaratıyor platformlar. Ayrıca, çoklu varlık blockchain olarak tek bir işlem birden fazla girdi ve çıktı içerebilir; burada her biri giriş herhangi bir token türünde olabilir; bu, Cosmos öğesinin doğrudan şu şekilde hizmet vermesini sağlar: emirlerin varsayılmasına rağmen merkezi olmayan değişim için bir platformdiğer platformlar aracılığıyla eşleştirilecek. Alternatif olarak bir bölge hizmet verebilir Dağıtılmış, hataya dayanıklı bir borsa olarak (sipariş defterleri ile), mevcut merkezi sisteme göre kesin bir gelişme olabilir zamanla saldırıya uğrama eğiliminde olan kripto para borsaları. Bölgeler ayrıca kurumsal işletmenin blockchain destekli sürümleri olarak da hizmet verebilir ve belirli bir hizmetin parçalarının bulunduğu hükümet sistemleri geleneksel olarak bir kuruluş veya kuruluşlar grubu tarafından yönetilir bunun yerine belirli bir bölgede ABCI uygulaması olarak çalıştırılır; Kamunun güvenliğini ve birlikte çalışabilirliğini devralmasına izin verir Temeldeki kontrolden ödün vermeden Cosmos ağı hizmet. Dolayısıyla Cosmos her iki dünyanın da en iyisini sunabilir blockchain teknolojisini kullanmak isteyen ancak Kontrolü tamamen dağıtılmış bir üçüncüye bırakma konusunda ihtiyatlı davranın parti. Bazıları tutarlılığı tercih etmenin büyük bir sorun olduğunu iddia ediyor Tendermint gibi fikir birliği algoritmaları, herhangi bir ağın
⅔ ile tek bir bölümün olmamasına neden olan bölüm oylama gücü (örneğin ≥⅓ fanzinden çıkmak) fikir birliğini tamamen durduracaktır. Cosmos mimarisi, aşağıdakileri kullanarak bu sorunun azaltılmasına yardımcı olabilir: oy verme yetkisinin olduğu bölgesel özerk bölgelere sahip küresel bir merkez her bölge için ortak bir coğrafi temele göre dağıtılır bölge. Örneğin, ortak bir paradigma bireysel olabilir. şehirleri veya bölgeleri paylaşırken kendi bölgelerini işletmek ortak merkez (ör. Cosmos Merkez), belediye faaliyetlerinin hub'ın geçici bir ağ nedeniyle durması durumunda devam etmesi bölüm. Bunun gerçek jeolojik, politik ve Sağlam tasarımda dikkate alınması gereken ağ topolojik özellikleri Birleşik hataya dayanıklı sistemler.
NameCoin bu sorunu çözmeye çalışan ilk blockchain'lardan biriydi. Bitcoin blockchain uyarlanarak ad çözümleme sorunu. Ne yazık ki bu yaklaşımla ilgili çeşitli sorunlar yaşandı. Namecoin ile örneğin @satoshi'nin olduğunu doğrulayabiliriz. Geçmişte bir noktada belirli bir genel anahtarla kayıtlı olan, ancak genel anahtarın o zamandan beri kullanılıp kullanılmadığını bilemiyoruz. sonuncusundan bu yana tüm blokları indirmediğimiz sürece yakın zamanda güncellendi bu ismin güncellenmesi. Bunun nedeni Bitcoin'nin sınırlamasıdır UTXO işlem Merkleleştirme modeli; burada yalnızca işlemler (ancak değiştirilebilir uygulama durumu değil) Merkle'lidir hash bloğuna. Bu, bir ismin daha sonraki güncellemelerinin var olmadığını değil, varlığını kanıtlamamızı sağlar. Bu nedenle bunu bilemeyiz tam olarak güvenmeden bir ismin en son değerini kesin olarak belirlemek indirerek bant genişliğinde önemli maliyetlere neden olmak tamamı blockchain. NameCoin'de Merkle'li bir arama ağacı uygulanmış olsa bile, proof-of-work bağımlılığı, hafif istemci doğrulamasını sağlar sorunlu. Light istemcilerin tam bir kopyasını indirmeleri gerekir. blockchain'un tamamındaki tüm bloklar için başlıklar (veya en azından bir ismin son güncellemesinden bu yana başlıklar). Bu şu anlama gelir: bant genişliği gereksinimleri zaman miktarıyla doğrusal olarak ölçeklenir [21]. Ayrıca proof-of-work blockchain numaralı telefondaki ad değişiklikleri ek proof-of-work onaylama bloklarının beklenmesini gerektirir, Bitcoin tarihinde bu işlem bir saate kadar sürebilir. Tendermint ile ihtiyacımız olan tek şey en son blok-hash validators'lik bir çoğunluk (oy gücüne göre) ve bir Merkle tarafından imzalandı isimle ilişkili mevcut değerin kanıtı. Bu onu yapar kısa ve öz, hızlı ve güvenli bir ışık istemcisine sahip olmak mümkün ad değerlerinin doğrulanması. Cosmos'de bu konsepti alıp daha da genişletebiliriz. Her biri Cosmos içindeki ad kayıt bölgesi, ".com" veya ".org" gibi ilişkili bir üst düzey alan (TLD) adına sahip olabilir ve her ad-
kayıt bölgesinin kendi yönetimi ve kaydı olabilir kurallar.
治理与经济
虽然 Cosmos Hub 是一个多资产分布式账本,但 一个特殊的原生 token 称为原子。原子是唯一的 staking Cosmos 中心的 token。原子是持有者的许可证 投票、验证或委托给其他 validator。就像 Ethereum 的 以太,原子也可以用来支付交易费用 减少垃圾邮件。额外的信息原子和区块交易 费用奖励给 validator 和委托给的委托人 validators。 BurnAtomTx 交易可用于恢复任何 从储备池中按比例分配 token。 Genesis 上原子 tokens 和 validators 的初始分布 将捐给 Cosmos 筹款活动的捐助者 (75%),主要捐助者 (5%)、Cosmos 网络基金会 (10%) 和 ALL IN BITS, Inc (10%)。从创世开始,原子总数的 1/3 将 每年都会奖励给绑定的 validator 和委托人。 有关更多详细信息,请参阅 Cosmos 计划。 与 Bitcoin 或其他 proof-of-work blockchain 不同,Tendermint 由于 validator 的数量增加,blockchain 会变慢 通信复杂性。幸运的是,我们可以支持足够多的人 validators 打造强大的全球分布式 blockchain 具有非常快的交易确认时间和带宽,
存储和并行计算能力的增加,我们将能够 将来支持更多 validator。 在创世日,validator 的最大数量将设置为 100,并且这个数字将在10年内以13%的速度增长,并且 稳定在 300 validators。 尚未成为 validators 的 Atom 持有者可以通过以下方式成为 validators: 签署并提交 BondTx 交易。金额 作为抵押品提供的原子必须非零。任何人都可以成为 a validator 在任何时候,除非当前的大小 validator 设置大于 validator 的最大数量 允许。在这种情况下,交易仅在金额达到 原子数大于所持有的有效原子数 最小的 validator,其中有效原子包括委托原子。 当新的 validator 以这种方式替换现有的 validator 时, 现有的 validator 变得不活跃,所有原子和 委托原子进入脱键状态。 必须对 validator 处以任何处罚 有意或无意偏离制裁规定 协议。有些证据可以立即采纳,例如 在相同的高度和轮次处进行双重签名,或者违反 第 0 年:100 第一年:113 第二年:127 第三年:144 第四年:163 5 年:184 第六年:208 7 年:235 8 年:265 9 年:300 10 年:300 ...
“prevote-the-lock”(Tendermint 共识协议的规则)。 此类证据将导致 validator 失去良好信誉 及其键合原子以及 tokens 的比例份额 储备池——统称为“股份”——将被削减。 有时,由于区域原因,validators 将不可用 网络中断、电源故障或其他原因。如果,在任何 在过去的 ValidatorTimeoutWindow 块中,validator 的点 提交投票未包含在 blockchain 中超过 ValidatorTimeoutMaxAbsent 次,validator 将变为 不活动,并失去其 ValidatorTimeoutPenalty(默认 1%) 股份。 一些“恶意”行为不会产生明显可辨别的结果 blockchain 上的证据。在这些情况下,validator 可以 带外协调以强制这些恶意软件超时 validators,如果达成绝大多数共识。 在 Cosmos 集线器因 ≥⅓ 联盟而停止的情况下 投票权消失,或者在 ≥⅓ 联盟的情况下 投票权审查的恶意行为证据 进入blockchain,集线器必须通过硬分叉恢复 重组提案。 (链接至“分叉和审查攻击”)。 Cosmos 集线器 validators 可接受任何 token 类型或组合 作为处理交易的费用的类型。每个 validator 可以 主观设定想要的汇率,然后选择 无论它想要什么交易,只要 BlockGasLimit 是 没有超过。收取的费用减去下面指定的任何税费, 按比例重新分配给担保利益相关者 他们的键合原子,每个 ValidatorPayoutPeriod (默认 1 小时)。在收取的交易费用中,保留税(默认 2%)将 前往储备池增加储备池并 提高 Cosmos 网络的安全性和价值。这些 资金也可以根据决定进行分配 由治理体系制定。 将投票权委托给其他 validator 的 Atom 持有者 向受委托人 validator 支付佣金。委员会可以 由每个 validator 设置。 Cosmos 集线器的安全性取决于 底层 validator 以及委托人的委托选择。 为了鼓励发现并及早报告所发现的 漏洞,Cosmos 中心鼓励黑客发布 通过 ReportHackTx 交易成功利用该交易,该交易表示:“这 validator 被黑了。请将赏金发送至此地址”。之上 这样的漏洞,validator 和委托人将变得不活跃, 每个人的原子都会受到 HackPunishmentRatio(默认 5%) 削减,以及每个人原子的 HackRewardRatio(默认 5%) 将获得奖励至黑客的赏金地址。 validator 必须使用其备份密钥恢复剩余的原子。 为了防止该功能被滥用进行转账 未归属原子,已归属原子与未归属原子的部分 ReportHackTx 之前和之后的 validators 和委托人将 保持不变,黑客赏金将包括一些 未归属的原子,如果有的话。 Cosmos 中心由一个分布式组织运营,该组织 需要一个明确的治理机制 协调对 blockchain 的各种更改,例如变量
系统参数,以及软件升级和 宪法修正案。 所有 validator 负责对所有提案进行投票。未能 及时对提案进行投票将产生 validator 自动停用一段时间,称为 缺勤处罚期(默认 1 周)。 委托人自动继承被委托人的投票权 validator。该投票可能会被手动覆盖。未键合的原子 没有投票权。 每个提案都需要缴纳最低提案存款 (MinimumProposalDeposit) tokens,可以是一个或多个tokens的组合 包括原子。对于每项提案,选民可以投票通过 押金。如果超过半数选民选择投票 存款(例如,因为该提案是垃圾邮件),存款将转到 储备池,除了被燃烧的任何原子。 对于每项提案,选民可以对以下选项进行投票: 是啊 力挺 不 强行反对 弃权 绝对多数赞成票或 YeaWithForce 票(或反对票或反对票) NayWithForce 投票)需要提案被决定为 通过(或判定失败),但 1/3+ 可以否决多数 通过“强力”投票做出决定。当绝对多数被否决时, 每个人都会因失去 VetoPenaltyFeeBlocks 而受到惩罚 (默认 1 天的区块)价值的费用(税费除外) 不会受到影响),以及否决多数票的一方
决定将受到失去 VetoPenaltyAtoms 的额外惩罚 (默认 0.1%)其原子。 此处定义的任何参数都可以通过以下命令更改 传递 ParameterChangeProposal。 原子可以被注入,储备池资金可以用在 通过赏金提案。 所有其他提案,例如升级协议的提案, 将通过通用的 TextProposal 进行协调。 参见计划。 blockchain 共识有很多创新, 过去几年的可扩展性。本节提供了一个简短的 对选定的一些重要问题进行的调查。 存在恶意参与者的共识是一个问题 可以追溯到 20 世纪 80 年代初,当时 Leslie Lamport 创造了 短语“拜占庭错误”指的是任意进程行为 与“崩溃故障”相比,偏离了预期的行为, 其中一个进程简单地崩溃了。发现了早期的解决方案 对于有上限的同步网络消息延迟,尽管实际使用仅限于高度 受控环境,例如飞机控制器和 通过原子钟同步的数据中心。直到 90 年代末,实用拜占庭容错 (PBFT) [11] 作为有效的部分同步共识引入 算法能够容忍多达 ⅓ 的进程行为 任意地。 PBFT 成为标准算法,催生了许多 变体,包括 IBM 最近创建的一个变体,作为 他们对超级账本的贡献。 Tendermint 共识对 PBFT 的主要好处是 Tendermint 具有改进和简化的底层结构, 其中一些是采用 blockchain 范式的结果。 Tendermint 区块必须按顺序提交,这可以避免 与 PBFT 相关的复杂性和通信开销 视图更改。在 Cosmos 和许多加密货币中,没有 需要允许块 N+i(其中 i >= 1)提交,当块 N 本身还没有承诺。如果带宽是阻止 N 的原因 尚未在 Cosmos 区域中提交,那么使用它无济于事 N+i 块的带宽共享投票。如果网络分区或 ofzine节点是区块N没有提交的原因,那么 无论如何,N+i 都不会承诺。 此外,将交易分批放入区块允许 应用程序状态的常规 Merkle-hashing,而不是 与 PBFT 的检查点方案一样的定期摘要。这允许 为轻客户端提供更快的可证明事务提交,并且速度更快 blockchain 之间的通信。 Tendermint Core 还包括许多优化和功能 超出 PBFT 中指定的范围。例如, validators 提出的区块被分成几个部分,默克尔化, 并以改善广播的方式传播八卦 性能(请参阅 LibSwift [19] 以获取灵感)。还有,嫩薄荷 Core 不做任何关于点对点的假设
只要 P2P 网络存在,连接性和功能就一直存在 弱连接。 虽然不是第一次部署 proof-of-stake (PoS),但 BitShares1.0 [12] 为 PoS 的研究和采用做出了巨大贡献 blockchains,特别是那些被称为“委托”PoS 的。在 比特股,利益相关者选举“见证人”,负责排序 并提交交易,以及“代表”,负责 协调软件更新和参数更改。 BitShares2.0旨在实现高性能(100k tx/s,1s 延迟)在理想条件下,每个块由单个签名 签名者和交易 ynality 花费的时间比 块间隔。规范规范仍在开发中。 利益相关者可以删除或更换行为不端的证人 每日进行,但没有重要的证人或证据 Tendermint PoS 中的委托人被削减 成功的双花攻击的情况。 基于 Ripple 首创的方法,Stellar [13] 雷尼德 联邦拜占庭协议模型,其中的过程 参与共识并不构成yxed和全球性的 已知集。相反,每个流程节点都会策划一个或多个 “仲裁切片”,每个切片构成一组可信进程。一个 Stellar 中的“quorum”被定义为包含以下内容的一组节点: 集合中的每个节点至少有一个仲裁片,这样 可以达成协议。 Stellar 机制的安全性依赖于以下假设 任意两个法定人数的交集非空,而 节点的可用性至少需要其仲裁片之一 完全由正确的节点组成,在之间创建一个权衡 使用可能难以平衡的大或小的仲裁片 无需对信任强加重大假设。最终,节点必须以某种方式选择足够的仲裁片 具有足够的容错能力(或任何“完整节点”,其中 论文的大部分结果取决于),并且唯一的 提供了确保这种配置是分层的策略 类似于边界网关协议 (BGP),互联网上的顶级 ISP 使用它来建立全球路由表,并且 浏览器用来管理 TLS 证书;都臭名昭著 因为他们的不安全感。 Stellar 论文中对基于 Tendermint 的权益证明系统的批评通过所描述的 token 策略得到了缓解 这里,发出了一种称为原子的新类型 token 代表对未来部分费用和奖励的要求。的 那么,基于 Tendermint 的 proof-of-stake 的优势是它的相对优势 简单性,同时仍然提供充分且可证明的安全性 保证。 BitcoinNG 是对 Bitcoin 的拟议改进,允许 对于垂直可扩展性的形式,例如增加块大小, 不会产生通常相关的负面经济后果 有了这样的变化,比如不成比例的巨大影响 关于小矿工。这种改进是通过分离来实现的 交易广播中的领导者选举:领导者是第一名 由 proof-of-work 在“微块”中选出,然后能够 广播要提交的交易,直到出现新的微块 被发现。这降低了所需的带宽要求 赢得 PoW 竞赛,让小矿工更公平地竞争, 并允许交易更定期地由 最后一个矿工创建一个微块。 Casper [16] 是一种提议的 proof-of-stake 共识算法 Ethereum。其主要运作模式是“投注共识”。由 让 validators 迭代地押注他们认为会出现的区块
根据其他赌注投入 blockchain 到目前为止,他们已经看到,最终可以实现 ynality。关联。 这是 Casper 团队的一个活跃研究领域。的 挑战在于构建一个可以 被证明是一种进化稳定的策略。主要好处是 Casper 与 Tendermint 相比可能在于提供“可用性” 过度一致性”——共识不需要>⅔法定人数 投票权 – 可能以牺牲提交速度或 实施复杂度。 Interledger 协议 [14] 严格来说并不是一个可扩展性解决方案。它 提供不同账本之间的临时互操作 系统通过松散耦合的双边关系网络。 与闪电网络一样,ILP 的目的是促进 支付,但它特别关注不同领域的支付 账本类型,并将原子交易机制扩展到 不仅包括 hash-锁,还包括法定人数的公证人(称为 原子传输协议)。后一种机制用于 在账本间交易中强制执行原子性类似于 Tendermint 的轻客户端 SPV 机制,因此说明 ILP 和 Cosmos/IBC 之间的区别是有保证的,并且 下面提供。 1. ILP中连接器的公证人不支持会员资格 变化,并且不允许在之间进行灵活的权重 公证人。另一方面,IBC 是专门为 blockchains,其中 validators 可以有不同的权重,并且 成员资格可以在整个过程中发生变化 blockchain。 2. 与闪电网络一样,ILP中的付款接收方 必须在线才能将确认信息发送回发件人。在一个token 通过 IBC 传输,即接收器的 validator 集 blockchain 负责提供确认,而不是 接收用户。 3. 最显着的区别是 ILP 的连接器不是 对付款负责或保持权威状态, 而在 Cosmos 中,集线器的 validator 是 IBC token 的状态转移以及权限 每个区域持有的 token 数量(但不是 区域内每个账户持有的 tokens)。这是 允许安全不对称的根本性创新 将 tokens 从一个区域转移到另一个区域; ILP 的类似物 Cosmos 中的连接器是持久且高度安全的 blockchain 分类账,Cosmos 中心。 4. ILP 中的账本间支付需要有一个 交换订单簿,因为不存在非对称转移 硬币从一个分类账到另一个分类账,仅转移价值或 市场等价物。 侧链 [15] 是一种提议的用于扩展 Bitcoin 的机制 通过“双向挂钩”的替代 blockchain 网络 Bitcoin blockchain。 (双向挂钩相当于 桥接。在 Cosmos 中,我们说“桥接”以区别于市场挂钩)。侧链允许比特币有效地从 Bitcoin blockchain 到侧链和后面,并允许 侧链新功能的实验。正如在 Cosmos Hub、侧链和 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 特别是关于 tokens。紫红色是关于缩放 一般计算。 Cosmos 未绑定到 EVM,因此即使不同的虚拟机也可以 互操作。 Cosmos 让区域创建者确定谁验证该区域 区。 任何人都可以在 Cosmos 中启动一个新区域(除非治理 另有决定)。 集线器隔离区域故障,因此全局 token 不变量是 保存下来。 闪电网络是提议的 token 传输网络 在 Bitcoin blockchain (以及其他公共 blockchains),实现多个数量级的改进 通过移动大部分交易来提高交易吞吐量 在共识账本之外进入所谓的“支付渠道”。这是通过链上加密货币脚本实现的,该脚本 使各方能够签订双边国家合同,其中 状态可以通过共享数字签名和合约来更新 可以通过将证据发布到 blockchain 来关闭,a 这种机制最早是通过跨链原子交换而普及的。由 与多方、参与者开放支付渠道 闪电网络可以成为路由的焦点 他人支付,形成全连接的支付通道 网络,代价是资金被束缚在支付渠道上。 虽然闪电网络也可以轻松地跨 多个独立的 blockchain 允许价值转移 通过交易市场,它不能被用来不对称地 将 token 从一个 blockchain 转移到另一个。主要收益 这里描述的 Cosmos 网络的目的是启用这种直接 token 转账。也就是说,我们期望支付渠道和 闪电网络将与我们一起被广泛采用 token 传输机制,出于节省成本和隐私的原因。 隔离见证是一个 Bitcoin 改进提案链接, 旨在将每块交易吞吐量提高 2 倍或 3 倍, 同时使新节点的块同步速度更快。 该解决方案的出色之处在于它如何在 Bitcoin 当前协议的限制并允许软分叉 升级(即使用旧版本软件的客户端将 升级后继续使用)。 Tendermint,成为新的 协议,没有设计限制,所以它有不同的缩放比例 优先事项。 Tendermint 主要使用 BFT 循环算法 基于加密签名而不是挖掘,这 简单地允许通过多个并行进行水平缩放 blockchains,而定期、更频繁的块提交允许 垂直缩放也是如此。
Yönetişim ve Ekonomi
Cosmos Hub çok varlıklı dağıtılmış bir defter olsa da, atom adı verilen özel bir yerli token. Atomlar tek staking Cosmos Hub'ın token. Atomlar, sahibine ait bir lisanstır. oy verin, doğrulayın veya diğer validator'lere yetki verin. Ethereum gibi eter, atomlar aynı zamanda işlem ücretlerini ödemek için de kullanılabilir spam'ı azaltın. Ek şişirici atomlar ve blok işlemi ücretler validator'lere ve yetki veren delegelere ödüllendirilir validators. BurnAtomTx işlemi herhangi bir veriyi kurtarmak için kullanılabilir. rezerv havuzundan orantılı miktarda tokens. tokens ve validators atomunun Genesis'teki ilk dağılımı Cosmos Bağış Kampanyasının bağışçılarına (%75), lider bağışçılara gidecek (%5), Cosmos Network Foundation (%10) ve ALL IN BITS, Inc. (%10). Oluşumdan itibaren toplam atom miktarının 1/3'ü her yıl kefil validator'lere ve delegelere ödüllendirilecektir. Ek ayrıntılar için Cosmos Plana bakın. Bitcoin veya diğer proof-of-work blockchain'lerden farklı olarak, bir Tendermint Artan hız nedeniyle blockchain daha fazla validator ile yavaşlıyor iletişim karmaşıklığı. Neyse ki yeterince destek verebiliyoruz validators, küresel olarak sağlam bir şekilde dağıtılmış blockchain oluşturmak için çok hızlı işlem onaylama süreleriyle ve bant genişliği olarak,
depolama ve paralel bilgi işlem kapasitesi artışları sayesinde şunları yapabileceğiz: gelecekte daha fazla validator desteklemek için. Yaratılış gününde maksimum validators sayısı şu şekilde ayarlanacak: 100, bu sayı 10 yıl boyunca %13 oranında artacak, 300 validators'ye yerleşti. Henüz atom sahibi olmayanlar şu tarihe kadar validators olabilirler. bir BondTx işleminin imzalanması ve gönderilmesi. miktarı Teminat olarak sağlanan atomların sıfırdan farklı olması gerekir. Herkes olabilir Geçerli boyutun boyutu dışında herhangi bir zamanda validator validator kümesi maksimum validators sayısından daha büyük izin verildi. Bu durumda işlem ancak tutarı kadar geçerli olur. atomları, tutulan etkin atomların miktarından daha fazladır. en küçük validator; burada etkin atomlar, devredilen atomları içerir. Yeni bir validator mevcut bir validator öğesinin yerini bu şekilde aldığında, mevcut validator devre dışı kalır ve tüm atomlar ve delege edilen atomlar bağlanmamış duruma girer. validators'ye herhangi bir ceza uygulanması gerekir. yaptırımlardan kasıtlı veya kasıtsız sapma protokol. Bazı deliller derhal kabul edilebilir. aynı yükseklikte ve yuvarlakta çift işaret veya kuralların ihlali Yıl 0: 100 Yıl 1: 113 2. Yıl: 127 Yıl 3: 144 4. Yıl: 163 Yıl 5: 184 Yıl 6: 208 Yıl 7: 235 Yıl 8: 265 Yıl 9: 300 Yıl 10: 300 ...
"kilidi önceden oyla" (Tendermint konsensüs protokolünün bir kuralı). Bu tür kanıtlar validator'nin iyi itibarını kaybetmesine neden olacaktır ve bağlı atomlarının yanı sıra tokens'nin orantılı payı topluca "hissesi" olarak adlandırılan rezerv havuzu kesilecek. Bazen bölgesel nedenlerden dolayı validators kullanılamayabilir ağ kesintileri, elektrik kesintisi veya diğer nedenler. Eğer herhangi bir zamanda geçmiş ValidatorTimeoutWindow bloklarındaki bir nokta, bir validator taahhüt oyu blockchain sayısından fazlasına dahil edilmedi ValidatorTimeoutMaxAbsent kez, bu validator olur etkin değil ve ValidatorTimeoutPenalty'yi (VARSAYILAN %1) kaybedersiniz hisse. Bazı “kötü niyetli” davranışlar açıkça fark edilebilir sonuçlar doğurmaz blockchain ile ilgili kanıt. Bu durumlarda validators şunları yapabilir: Bu kötü amaçlı yazılımların zaman aşımını zorlamak için bant dışı koordinasyonu sağlayın validators, eğer çoğunlukta bir fikir birliği varsa. Cosmos Merkezin ≥⅓ koalisyon nedeniyle durduğu durumlarda Oy gücünün tükenmesi veya ≥⅓ koalisyonun olduğu durumlarda oy verme yetkisinin kötü niyetli davranışlara dair kanıtlarını sansürlemek blockchain'ye girildiğinde hub'ın hard fork ile kurtarılması gerekir yeniden düzenleme teklifi. (“Çatallar ve Sansür Saldırıları”na bağlantı). Cosmos Hub validator'ler herhangi bir token türünü veya kombinasyonunu kabul edebilir Bir işlemin işlenmesine ilişkin ücretler gibi türler. Her validator şunları yapabilir: istediği döviz kurunu öznel olarak belirler ve seçer BlockGasLimit olduğu sürece istediği işlemler ne olursa olsun aşılmadı. Toplanan ücretlerden aşağıda belirtilen vergiler düşüldükten sonra, bağlı hissedarlara orantılı olarak yeniden dağıtılır. bağlı atomları, her ValidatorPayoutPeriod (VARSAYILAN 1 saat).Toplanan işlem ücretlerinden ReserveTax (VARSAYILAN %2) rezerv havuzunu arttırmak için rezerv havuzuna gidin ve Cosmos ağının güvenliğini ve değerini artırın. Bunlar fonlar da kararlara uygun olarak dağıtılabilir yönetim sistemi tarafından yapılmıştır. Oy verme yetkisini diğer validator'lere devreden atom sahipleri Yetki verilen validator'ye komisyon ödeyin. Komisyon şunları yapabilir: her validator tarafından ayarlanabilir. Cosmos Hub'ın güvenliği, temel validators ve yetki verenlerin yetki seçimi. Bulunanların keşfedilmesini ve erken raporlanmasını teşvik etmek amacıyla Cosmos Hub, bilgisayar korsanlarını güvenlik açıklarını yayınlamaya teşvik ediyor "Bu, validator saldırıya uğradı. Lütfen bu adrese ödül gönderin”. üzerine böyle bir istismar durumunda validator ve yetki verenler pasif hale gelecektir, Herkesin atomlarının HackPunishmentRatio (varsayılan %5'i) alınacak kesildi ve herkesin atomlarının HackRewardRatio'su (varsayılan %5) hackerın ödül adresine ödüllendirilecek. validator kalan atomları yedek anahtarlarını kullanarak kurtarmaları gerekir. Bu özelliğin kötüye kullanılmasını önlemek için aktarıma yatırımsız atomlar, yatırımsız atomlara karşı yatırımsız atomların kısmı validator'ler ve delegeler ReportHackTx'ten önce ve sonra aynı kalacak ve hacker ödülü bazı varsa, yatırımsız atomlar. Cosmos Hub, dağıtılmış bir kuruluş tarafından işletilmektedir. iyi tasarlanmış bir yönetim mekanizmasına ihtiyaç duymaktadır. değişken gibi blockchain'deki çeşitli değişiklikleri koordine edin
sistem parametrelerinin yanı sıra yazılım yükseltmeleri ve anayasa değişiklikleri. Tüm validator'ler tüm tekliflere oy vermekten sorumludur. başarısız Bir teklife zamanında oy vermek validator ile sonuçlanacaktır adı verilen bir süre boyunca otomatik olarak devre dışı bırakılır. Devamsızlık Cezası Süresi (VARSAYILAN 1 hafta). Delege edenler, delege edilenlerin oylarını otomatik olarak devralır validator. Bu oy manuel olarak geçersiz kılınabilir. Bağlanmamış atomlar oy alamamak Her teklif için MinimumProposalDeposit tutarında bir depozito gerekir tokens; bir veya daha fazla tokens'nin birleşimi olabilir atomlar dahil. Seçmenler her öneri için oy kullanabilirler. depozito. Seçmenlerin yarısından fazlası seçime girerse depozito (ör. teklifin spam olması nedeniyle), depozito şu adrese gider: yakılan atomlar hariç yedek havuz. Her öneri için seçmenler aşağıdaki seçeneklerle oy kullanabilir: Evet EvetWithForce Hayır NayWithForce Çekimser Evet veya YeaWithForce oylarının tam çoğunluğu (veya Hayır veya Teklifin şu şekilde karara bağlanması için NayWithForce oyu gereklidir) geçti (veya başarısız olduğuna karar verildi), ancak 1/3+ çoğunluğu veto edebilir “zorla” oy kullanarak karar verir. Kesin çoğunluk veto edildiğinde, herkes VetoPenaltyFeeBlocks'u kaybederek cezalandırılır (VARSAYILAN 1 günlük blok değerinde) tutarında ücret (vergiler hariç) etkilenmeyecektir) ve çoğunluğu veto eden taraf
karar ayrıca VetoPenaltyAtoms'un kaybedilmesiyle cezalandırılacaktır (VARSAYILAN %0,1) atomlarının. Burada tanımlanan parametrelerden herhangi biri değiştirilebilir. bir ParameterChangeProposal'ın iletilmesi. Atomlar şişirilebilir ve havuz fonları harcanabilir. Bir Ödül Teklifinin kabul edilmesi. Protokolün yükseltilmesi teklifi gibi diğer tüm teklifler, genel TextProposal aracılığıyla koordine edilecektir. Plana bakınız. blockchain fikir birliğinde birçok yenilik oldu ve Son birkaç yılda ölçeklenebilirlik. Bu bölüm kısa bir bilgi sağlar seçilmiş sayıda önemli olanın araştırılması. Kötü niyetli katılımcıların varlığında fikir birliği bir sorundur Leslie Lamport'un icat ettiği 1980'lerin başlarına kadar uzanıyor. "Bizans hatası" ifadesi, keyfi süreç davranışını ifade eder. “Çarpışma hatasının” aksine, amaçlanan davranıştan saparsa, burada bir süreç basitçe çöküyor. Erken çözümler keşfedildi bir üst sınırın olduğu senkronize ağlar içinmesaj gecikmesi, ancak pratik kullanım oldukça sınırlıydı uçak kontrolörleri gibi kontrollü ortamlar ve veri merkezleri atom saatleri aracılığıyla senkronize edilir. O zamana kadar değildi 90'ların sonlarında Pratik Bizans Hata Toleransının (PBFT) [11] olduğu Verimli, kısmen senkronize bir fikir birliği olarak tanıtıldı algoritma, davranan süreçlerin ⅓'üne kadar tolere edebilir keyfi olarak. PBFT standart algoritma haline geldi ve birçok kapsamında IBM tarafından en son oluşturulanlar da dahil olmak üzere varyasyonlar Hyperledger'a katkıları. PBFT üzerinde Tendermint fikir birliğinin ana avantajı şudur: Tendermint geliştirilmiş ve basitleştirilmiş bir temel yapıya sahiptir, bunlardan bazıları blockchain paradigmasını benimsemenin bir sonucudur. Tendermint blokları sırayla işlenmelidir, bu da PBFT ile ilişkili karmaşıklık ve iletişim ek yükü görünüm değişiklikleri. Cosmos ve birçok kripto para biriminde N bloğu olduğunda i >= 1'in işleme alınması için N+i bloğuna izin verilmesi gerekir kendisi henüz taahhütte bulunmadı. N bloğunun nedeni bant genişliği ise Cosmos bölgesinde taahhütte bulunmadıysa, kullanılmasına yardımcı olmaz N+i blokları için bant genişliği paylaşımı oyları. Bir ağ bölümü veya N bloğunun taahhüt edilmemesinin nedeni ofzine düğümleridir, o zaman N+i yine de taahhütte bulunmayacağım. Ayrıca işlemlerin bloklar halinde gruplandırılması, yerine uygulama durumunun düzenli Merkle-hashing'lenmesi PBFT'nın kontrol noktası şemasındaki gibi periyodik özetler. Bu izin verir hafif istemciler için daha hızlı kanıtlanabilir işlem taahhütleri ve daha hızlı blockchain arası iletişim. Tendermint Core ayrıca birçok optimizasyon ve özellik içerir PBFT'de belirtilenlerin ötesine geçen. Örneğin, validators tarafından önerilen bloklar Merkle'li parçalara bölünmüştür, ve yayıncılığı iyileştirecek şekilde dedikodu yapıldı performansı (ilham için bkz. LibSwift [19]). Ayrıca, Tendermint Core noktadan noktaya herhangi bir varsayımda bulunmaz
P2P ağı açık olduğu sürece bağlantı ve işlevler zayıf bağlantılı. proof-of-stake (PoS), BitShares1.0 [12] dağıtımını yapan ilk yıl olmasa da PoS'un araştırılmasına ve benimsenmesine önemli ölçüde katkıda bulundu blockchains, özellikle "yetkilendirilmiş" PoS olarak bilinenler. içinde BitShares, paydaşlar siparişten sorumlu "tanıkları" seçer işlemleri gerçekleştiren ve yürüten "temsilciler" yazılım güncellemelerini ve parametre değişikliklerini koordine etmek. BitShares2.0 yüksek performansa ulaşmayı hedefliyor (100k tx/s, 1s gecikme) ideal koşullarda, her bloğun tek bir kişi tarafından imzalandığı imzalayan kişi ve işlem bütünlüğü, imzalayandan biraz daha uzun sürüyor blok aralığı. Kanonik bir spesifikasyon halen geliştirilme aşamasındadır. Paydaşlar, uygunsuz davranan tanıkları bir platformda kaldırabilir veya değiştirebilir. günlük olarak, ancak önemli bir tanık veya tanık teminatı yoktur. Tendermint PoS benzeri delegeler kesildi Başarılı bir çift harcama saldırısı durumunda. Ripple'ın öncülüğünü yaptığı bir yaklaşımı temel alan Stellar [13], Federe Bizans Anlaşması modeli burada süreçler fikir birliğine katılmak yxed ve küresel bir anlaşma oluşturmaz bilinen küme. Bunun yerine, her süreç düğümü bir veya daha fazlasını seçer Her biri bir dizi güvenilir süreçten oluşan “çekirdek dilimleri”. bir Stellar içindeki “yesayı”nın, aşağıdakileri içeren bir düğüm kümesi olduğu tanımlanmaktadır: kümedeki her düğüm için en az bir yetersayı dilimi, öyle ki anlaşmaya varılabilir. Stellar mekanizmasının güvenliği şu varsayıma dayanır: herhangi iki yeter sayının kesişiminin boş olmadığı, ancak Bir düğümün kullanılabilirliği, çekirdek dilimlerinden en az birinin tamamen doğru düğümlerden oluşur ve bunlar arasında bir değiş-tokuş yaratır. Dengelenmesi zor olabilecek büyük veya küçük çekirdek dilimlerinin kullanılması Güvenle ilgili önemli varsayımlar empoze etmeden. Sonuçta,düğümlerin bir şekilde yeterli çekirdek dilimlerini seçmesi gerekir yeterli hata toleransı (veya herhangi bir "sağlam düğüm" olması, makalenin sonuçlarının çoğu buna bağlıdır) ve tek böyle bir yapılandırmanın hiyerarşik olmasını sağlamak için sağlanan strateji ve internetteki üst düzey ISP'ler tarafından küresel yönlendirme tabloları oluşturmak için kullanılan Sınır Ağ Geçidi Protokolüne (BGP) benzer ve TLS sertifikalarını yönetmek için tarayıcılar tarafından kullanılanlar; ikisi de meşhur güvensizlikleri için. Tendermint tabanlı hisse kanıtı sistemlerine ilişkin Stellar belgesindeki eleştiri, açıklanan token stratejisiyle hafifletildi burada atom adı verilen yeni bir token türü yayınlanır; ücret ve ödüllerin gelecekteki kısımlarına ilişkin talepleri temsil eder. Tendermint tabanlı proof-of-stake'nin avantajı görecelidir basitlik, aynı zamanda yeterli ve kanıtlanabilir güvenlik sağlarken garanti eder. BitcoinNG, Bitcoin için önerilen ve aşağıdakilere izin verecek bir iyileştirmedir: blok boyutunun arttırılması gibi dikey ölçeklenebilirlik biçimleri için, tipik olarak ilişkili olumsuz ekonomik sonuçlar olmadan orantısız derecede büyük etki gibi bir değişiklikle küçük madencilerde. Bu iyileştirme, ayrıştırılarak elde edilir. işlem yayınından lider seçimi: liderler ilk sırada proof-of-work tarafından "mikro bloklar" halinde seçildi ve ardından yeni bir mikro bloğa kadar gerçekleştirilecek yayın işlemleri Bulundu. Bu, gerekli bant genişliği gereksinimlerini azaltır. PoW yarışını kazanarak küçük madencilerin daha adil bir şekilde rekabet edebilmesini sağlayın, ve işlemlerin daha düzenli yapılmasına olanak sağlanması Mikro bloğu bulan son madenci. Casper [16] önerilen bir proof-of-stake fikir birliği algoritmasıdır. Ethereum. Başlıca çalışma şekli “bahse dayalı fikir birliği”dir. Tarafından validators'nin hangi blokta olacağına inandıkları üzerine yinelemeli olarak bahis oynamasına izin vermek
diğer bahislere bağlı olarak blockchain'ye bağlanın Şu ana kadar gördükleri gibi, sonunda aynılığa ulaşılabilir. bağlantı. Bu, Casper ekibinin aktif bir araştırma alanıdır. Buradaki zorluk, yapılabilecek bir bahis mekanizması oluşturmaktır. evrimsel olarak istikrarlı bir strateji olduğu kanıtlanmıştır. Başlıca faydası Casper, Tendermint ile karşılaştırıldığında "kullanılabilirlik" sunuyor olabilir aşırı tutarlılık” – fikir birliği >⅔ yeterli çoğunluk gerektirmez oylama gücü – belki taahhüt hızı pahasına veya uygulama karmaşıklığı. Interledger Protokolü [14] kesinlikle bir ölçeklenebilirlik çözümü değildir. o farklı defterler arasında geçici bir birlikte çalışma sağlar Gevşek bir şekilde bağlı ikili ilişkiler ağı aracılığıyla sistemler. Lightning Network gibi ILP'nin amacı da ödemeler, ancak özellikle farklı ödemeler arasındaki ödemelere odaklanıyor defter türleri ve atomik işlem mekanizmasını genişletir yalnızca hash kilitleri değil, aynı zamanda noter yetersayısını da içerir (buna denir) Atomik Taşıma Protokolü). için ikinci mekanizma Defterler arası işlemlerde atomikliğin uygulanması şuna benzer: Tendermint'in hafif istemci SPV mekanizması, yani ILP ve Cosmos/IBC arasındaki ayrım garanti edilir ve aşağıda verilmiştir. 1. ILP'deki bağlayıcının noterleri üyeliği desteklemez değişiklikler arasında zexible ağırlıklandırmaya izin vermeyin ve noterler. Öte yandan, IBC özellikle şunlar için tasarlanmıştır: blockchains; burada validators farklı ağırlıklara sahip olabilir ve üyeliğin dönem boyunca değişebileceği yer blockchain. 2. Lightning Network'te olduğu gibi ILP'de ödemenin alıcısı Gönderene onay gönderebilmek için çevrimiçi olmanız gerekir. birtoken, alıcının validator kümesi olan IBC üzerinden aktarım blockchain onayın sağlanmasından sorumludur, kullanıcıyı alıyor. 3. En çarpıcı fark, ILP'nin konnektörlerinin Ödemeler konusunda sorumlu veya yetkili devleti tutmak, Cosmos'de ise bir hub'ın validator'leri şu otoritenin yetkisindedir: IBC token eyaleti transferlerinin yanı sıra her bir bölgede tutulan tokens miktarı (ancak miktarı değil) token'ler bir bölge içindeki her hesapta tutulur). Bu Güvenli asimetriklik sağlayan temel yenilik token'lerin bölgeden bölgeye aktarılması; ILP'nin analogu Cosmos içindeki bağlayıcı kalıcı ve maksimum düzeyde güvenlidir blockchain defter, Cosmos Merkez. 4. ILP'deki defterler arası ödemelerin bir belgeyle desteklenmesi gerekir. Asimetrik transfer olmadığından takas emir defteri madeni paraların bir defterden diğerine aktarılması, yalnızca değerin veya piyasa eşdeğerleri. Yan zincirler [15], Bitcoin'yi ölçeklendirmek için önerilen bir mekanizmadır. "iki yönlü sabitlenmiş" alternatif blockchain'ler aracılığıyla ağ Bitcoin blockchain. (İki yönlü sabitleme şuna eşdeğerdir: köprüleme. Cosmos'de piyasa sabitlemeden ayırt etmek için "köprüleme" diyoruz). Yan zincirler, bitcoinlerin etkili bir şekilde hareket etmesini sağlar. Bitcoin blockchain yan zincire ve arkaya doğru ilerleyin ve aşağıdakilere izin verin: yan zincirdeki yeni özelliklerin denenmesi. Olarak Cosmos Hub, yan zincir ve Bitcoin hafif istemciler olarak hizmet eder madeni paraların ne zaman yatırılması gerektiğini belirlemek için SPV kanıtlarını kullanarak birbirlerine yan zincire ve arkaya aktarılır. Elbette, Bitcoin tarihinden beri proof-of-work kullanıyor, Bitcoin merkezli yan zincirler zarar görüyor proof-of-work'nın birçok sorunu ve riskinden dolayı Konsensüs mekanizması. Üstelik bu bir Bitcoin-maksimalist çeşitli token'leri yerel olarak desteklemeyen çözüm ve
Cosmos'un yaptığı gibi bölgeler arası ağ topolojisi. Bununla birlikte, çekirdek iki yönlü çivinin mekanizması prensipte bununla aynıdır Cosmos ağı tarafından kullanılıyor. Ethereum şu anda bir dizi farklı stratejiyi araştırıyor Ethereum blockchain adresinin durumunu parçalamak için ölçeklenebilirlik ihtiyaçları. Bu çabaların amacı, Geçerli Ethereum Sanal Makine tarafından sunulan soyutlama katmanı paylaşılan durum alanı boyunca. Çoklu araştırma çabaları şu sıralar sürüyor. [18][22] Cosmos ve Ethereum 2.0 Leylak rengi [22] farklı tasarım hedeflerine sahiptir. Cosmos özellikle tokens ile ilgilidir. Mauve ölçeklendirmeyle ilgilidir genel hesaplama. Cosmos EVM'ye bağlı değildir, dolayısıyla farklı VM'ler bile birlikte çalışabiliriz. Cosmos, bölgeyi oluşturanın bölgeyi kimin doğruladığını belirlemesine olanak tanır bölge. Cosmos bölgesinde herkes yeni bir alt bölge başlatabilir (yönetim olmadığı sürece) aksi yönde karar verir). Hub bölge hatalarını izole ederek global token değişmezlerinin korunmuş. Lightning Network önerilen bir token aktarım ağıdır Bitcoin blockchain (ve diğer genel) üzerindeki bir katmanda çalışan blockchains), birçok büyüklükte iyileştirmeye olanak sağlar işlemlerin çoğunluğunu taşıyarak işlem verimini artırın fikir birliği defterinin dışında sözde "ödeme kanallarına" aktarılır.Bu, zincir üstü kripto para birimi komut dosyalarıyla mümkün olmaktadır. Tarafların ikili devlet sözleşmeleri yapmalarına olanak sağlamak, dijital imzalar ve sözleşmeler paylaşılarak durum güncellenebilir kanıtların blockchain üzerinde Yynal olarak yayınlanmasıyla kapatılabilir. Mekanizma ilk olarak zincirler arası atomik takaslarla popüler hale getirildi. Tarafından Birçok tarafla ödeme kanallarının açılması, katılımcılar Lightning Network, yönlendirme için odak noktaları haline gelebilir başkalarının ödemeleri, tamamen bağlantılı bir ödeme kanalına yol açar sermayenin ödeme kanallarına bağlanması pahasına ağ. Lightning Network aynı zamanda kolaylıkla genişleyebilir. değer aktarımına izin vermek için birden fazla bağımsız blockchains bir döviz piyasası yoluyla asimetrik olarak kullanılamaz token'ları bir blockchain'den diğerine aktarın. Asıl fayda burada açıklanan Cosmos ağının amacı bu tür doğrudan token aktarımlar. Bununla birlikte, ödeme kanallarının ve Lightning Network, ürünlerimizle birlikte geniş çapta benimsenecek token aktarım mekanizması, maliyet tasarrufu ve gizlilik nedeniyle. Ayrılmış Tanık, bir Bitcoin iyileştirme teklifi bağlantısıdır. Blok başına işlem hacmini 2 kat veya 3 kat artırmayı hedefliyor, aynı anda yeni düğümler için blok senkronizasyonunu daha hızlı hale getirir. Bu çözümün mükemmelliği, sistem içinde nasıl çalıştığındadır. Bitcoin'nin mevcut protokolünün sınırlamaları vardır ve yumuşak çatala izin verir yükseltme (yani yazılımın eski sürümlerine sahip istemciler yükseltmeden sonra çalışmaya devam edin). Tendermint, yeni olmak protokolün tasarım kısıtlaması yoktur, dolayısıyla farklı bir ölçeklendirmeye sahiptir öncelikler. Tendermint öncelikle BFT hepsini bir kez deneme algoritması kullanır madencilik yerine kriptografik imzalara dayalı birden fazla paralel üzerinden yatay ölçeklendirmeye önemsiz bir şekilde izin verir blockchains, düzenli, daha sık blok işlemeleri izin verirken dikey ölçeklendirme de.
共识和技术细节
一个设计良好的共识协议应该提供一些 超出耐受能力时的保证 并且共识失败。这在经济上尤其必要 系统中,拜占庭行为可能会产生大量的经济影响 奖励。最重要的此类保证是一种责任形式,其中导致共识的过程 失败(即导致协议的客户端接受不同的值 - a fork)可以根据规则进行识别和惩罚 协议,或者可能是法律体系。当法律制度 不可靠或调用成本过高, validators 可能是 被迫缴纳保证金才能参加,以及那些 当恶意行为发生时,存款可以被撤销或削减 检测到 [10]。 请注意,这与 Bitcoin 不同,其中分叉是经常发生的 由于网络异步性和 ynding 的概率性质 部分 hash 碰撞。因为在很多情况下,恶意分叉是 由于异步,与分叉无法区分,Bitcoin 不能 可靠地实施分叉责任,而不是隐式的 矿工为开采孤立区块而支付的机会成本。 我们将投票阶段称为 PreVote 和 PreCommit。投票可以是 特定块或 Nil。我们称之为>⅔预投票的集合 对于同一轮 Polka 中的单个块,以及 >⅔ 的集合 在同一轮提交中预提交单个块。如果>⅔ 在同一轮中预提交为零,他们进入下一轮 圆形。 请注意,协议中的严格决定论会导致较弱的 同步假设,因为必须检测到错误的领导者并
跳过了。因此,validators 等待一段时间, TimeoutPropose,在 Prevote Nil 之前,以及值 TimeoutPropose 随着每一轮的增加而增加。进展通过 一轮的其余部分是完全异步的,因为进度只是 一旦 validator 收到来自 >⅔ 的网络消息。在实践中, 需要一个极其强大的对手才能无限期地挫败 弱同步假设(导致共识无法达成) 曾经提交过一个区块),这样做可以使更多 通过在每个上使用 TimeoutPropose 的随机值来实现困难 validator。 一组附加的约束或锁定规则,确保 网络最终将在每个高度只提交一个区块。任意 恶意尝试导致多个区块被提交 可以识别给定高度。首先,对块进行 PreCommit 必须以 Polka 的形式为该块提供合理性。 如果 validator 已经在 R_1 轮预提交了一个区块,我们 说他们被锁定在那个街区,波尔卡用来证明 R_2 轮的新 PreCommit 必须出现在 R_polka 轮中 其中 R_1 < R_polka <= R_2。其次,validators 必须提出 和/或对他们锁定的区块进行预投票。在一起,这些 条件确保 validator 不会在没有预提交的情况下进行预提交 有足够的证据作为正当理由,并且 validators PreCommit 已经无法为 PreCommit 提供证据 其他的东西。这既保证了安全性又保证了活跃性 共识算法。 此处描述了该协议的完整细节。 TendermintPoS 消除了同步所有区块头的需要,因为替代链(分叉)的存在意味着 ≥⅓ 担保权益可以被削减。当然,由于削减需要 有人分享分叉的证据,轻客户端应该存储 任何 block-hash 提交它看到的。此外,轻客户端可以定期与 validator 集的更改保持同步, 为了避免远程攻击(但其他解决方案是 可能)。 本着与 Ethereum 类似的精神,Tendermint 使应用程序能够 在每个块中嵌入一个全局 Merkle 根 hash ,从而轻松地允许 可验证的状态查询,例如帐户余额、价值 存储在合约中,或存在未花费的交易 输出,取决于应用程序的性质。 假设广播网络具有足够的弹性集合 和静态 validator 集,blockchain 中的任何分叉都可以 被发现并削减了违规 validator 的存款。这个 Vitalik Buterin 在 2014 年初提出的创新解决了 其他 proof-of-stake 的无利害关系问题 加密货币(参见相关工作)。但是,由于 validator 设置 必须能够在很长一段时间内改变原来的 validators 可能全部变为非绑定状态,因此可以自由 从创世块创建一条新链,不产生任何成本 他们不再锁定存款。这次攻击发生了 与短程攻击相比,称为远程攻击 (LRA) 范围攻击,当前绑定的 validator 会造成 分叉,因此会受到惩罚(假设分叉负责 BFT 像 Tendermint 共识这样的算法)。远程攻击是 通常被认为是对 proof-of-stake 的致命打击。 幸运的是,LRA 可以通过以下方式缓解。首先,对于一个 validator 解绑(从而收回其抵押存款 并且不再赚取参与共识的费用), 存款必须在一段时间内不可转让 称为“解绑期”,可能约为 几周或几个月。其次,为了保证轻客户端的安全,第一 当它连接到网络时,它必须验证最近的块-hash 针对可信来源,或者最好是多个来源。这个
这种情况有时被称为“弱主观性”。最后, 为了保持安全,它必须与最新的 validator 设置同步 最少与解绑期的长度一样频繁。这个 确保轻客户端知道 validator 的更改 在 validator 的资本解除绑定之前设置,因此不再 处于危险之中,这将使其能够通过执行来欺骗客户 通过从某个位置开始创建新块来进行远程攻击 它粘合的高度(假设它有足够的控制 许多早期的私钥)。 请注意,以这种方式克服 LRA 需要彻底修改 proof-of-work 的原始安全模型。在 PoW 中,是 假设轻客户端可以从 只需处理每个块头中的工作量证明即可随时获得可信创世块。然而,为了战胜上帝抵抗军,我们 要求轻客户端定期上线 跟踪 validator 集中的变化,并且第一时间他们 上网时他们必须特别小心地进行身份验证 他们从网络上听到的来自可信来源的信息。的 当然,后一个要求类似于 Bitcoin 的要求,其中 协议和软件还必须从受信任的机构获得 来源。 上述预防 LRA 的方法非常适合 validators 以及 Tendermint 支持的 blockchain 的完整节点,因为这些 节点旨在保持与网络的连接。的 该方法也适用于可以预期的轻客户端 经常与网络同步。然而,对于轻量级客户来说 预计不会经常访问互联网或 blockchain 网络,可以使用另一种解决方案来克服 圣主抵抗军。非 validator token 持有者可以将其 token 发布为 具有很长解绑期限的抵押品(例如更长的 超过 validators 的解绑期)并为轻客户端提供服务 使用第二种方法来证明当前和的有效性 过去的区块-hashes。虽然这些 token 不计入 blockchain 共识的安全性,但他们仍然可以为轻客户提供有力保障。如果历史区块-hash Ethereum 支持查询,任何人都可以绑定他们的 tokens 在专门设计的 smart contract 中并提供 付费认证服务,有效地为轻客户端 LRA 安全创造了市场。 由于块提交的定义,任何 ≥⅓ 的联盟 投票权可以通过是否关闭 blockchain 来阻止 blockchain 广播他们的选票。这样的联盟也可以审查 通过拒绝包含这些的块来特定交易 交易,尽管这会导致相当大的比例 的区块提案被拒绝,这将减慢速度 blockchain 的块提交,降低了其实用性和价值。 恶意联盟也可能会少量广播投票,以便 为了磨炼 blockchain 块,承诺几乎停止,或从事 这些攻击的任意组合。最后,它可能会导致 blockchain 通过双重签名或违反锁定来分叉 规则。 如果全球活跃的对手也参与其中,它可能会分裂 网络的方式可能会出现错误 validator 的子集导致了速度下降。这不是 只是 Tendermint 的限制,而是所有的限制 其网络可能由某个人控制的共识协议 积极的对手。 对于这些类型的攻击,validator 的子集应该 通过外部手段协调签署重组提案 选择一个分叉(及其任何证据)和初始子集 validator 及其签名。签署此类重组提案的验证者将放弃所有其他分叉上的抵押品。客户应该 验证重组提案上的签名,验证任何证据, 并做出判断或提示最终用户做出决定。对于 例如,手机钱包应用程序可能会提示用户安全
警告,而冰箱可以接受任何重组建议 由原始 validator 的 +1/2 投票权签署。 没有非同步的拜占庭容错算法可以来 当 ≥⅓ 的投票权不诚实时达成共识,但仍存在分叉 假设 ≥⅓ 的投票权已经被不诚实 没有正当理由的双重签名或锁更改。所以,签 重组提案是一个协调问题,无法解决 通过任何非同步协议解决(即自动,并且 不对可靠性做出假设 底层网络)。目前,我们将重组提案的协调问题留给人类通过社会共识进行协调 在网络媒体上。验证者必须注意确保 在签署重组提案之前没有剩余的网络分区,以避免签署两个相互冲突的重组提案的情况。 假设外部协调介质和协议是 稳健,因此与审查相比,分叉更受关注 攻击。 除了分叉和审查,需要≥⅓拜占庭 投票权,超过⅔投票权的联盟可以承诺 任意的、无效的状态。这是任何 (BFT) 的特征 共识系统。与创建分叉的双重签名不同 通过易于验证的证据,检测某人的承诺 无效状态需要非验证节点来验证整个块, 这意味着他们保留状态的本地副本并执行 每笔交易,独立计算状态根 他们自己。一旦检测到,处理此类故障的唯一方法 是通过社会共识。例如,在 Bitcoin 的情况下 失败了,是否由于软件 bug 导致分叉(如 3 月份 2013),或者由于拜占庭行为而提交无效状态 矿工(截至 2015 年 7 月),紧密联系的社区 企业、开发商、矿工和其他组织 关于什么是手动操作建立了社会共识参与者需要治愈网络。此外,由于 Tendermint blockchain 的 validator 可能预计为 无效国家的承诺甚至可能是可识别的 如果需要的话,可以受到法律或某些外部判例的惩罚。 ABCI 由 3 种主要消息类型组成,这些消息类型从 应用程序的核心。应用程序回复 相应的响应消息。 AppendTx 消息是应用程序的主力。每个 blockchain 中的事务随此消息一起传递。的 应用程序需要验证收到的每笔交易 针对当前状态、应用程序协议的 AppendTx 消息, 以及交易的加密凭证。经过验证的 然后事务需要更新应用程序状态 - 通过 将值绑定到键值存储中,或者通过更新 UTXO 数据库。 CheckTx 消息与 AppendTx 类似,但仅适用于 验证交易。 Tendermint Core 的内存池首次检查 与 CheckTx 交易的有效性,并且仅中继有效 与其同行的交易。应用程序可以检查递增 nonce 在交易中,并在 CheckTx 上返回错误,如果 nonce 已旧。 “提交”消息用于计算密码 对当前应用程序状态的承诺,将被放入 下一个块头。这有一些方便的属性。 更新该状态时的不一致现在将显示为 blockchain fork 捕获整个类的编程 错误。这也简化了安全轻量化的开发 客户,因为 Merkle-hash 证明可以通过检查来验证 区块-hash,区块-hash由法定人数签名 validators(按投票权)。
额外的 ABCI 消息允许应用程序跟踪 并更改 validator 设置,并让应用程序接收 区块信息,例如高度和提交投票。 ABCI 请求/响应是简单的 Protobuf 消息。检查 出架构yle。 论据: 数据([]byte):请求交易字节 返回: 代码 (uint32):响应代码 数据([]byte):结果字节(如果有) 日志(字符串):调试或错误消息 用途:
追加并运行事务。如果交易有效, 返回 CodeType.OK 论据: 数据([]byte):请求交易字节 返回: 代码 (uint32):响应代码 数据([]byte):结果字节(如果有) 日志(字符串):调试或错误消息 用途:
验证交易。此消息不应改变 状态。交易首先通过 CheckTx 运行 广播到内存池层中的对等点。你可以使 CheckTx 半状态并在提交时清除状态或 BeginBlock ,允许依赖的交易序列 在同一个街区。
返回: 数据([]byte):Merkle 根 hash 日志(字符串):调试或错误消息 用途:
返回应用程序状态的 Merkle 根 hash。 论据: Data ([]byte) :查询请求字节 返回: 代码 (uint32):响应代码 数据([]byte):查询响应字节 日志(字符串):调试或错误消息 用途:
刷新响应队列。实施的应用程序 types.Application 不需要实现此消息 - 它是 由项目处理。 返回: 数据([]byte):信息字节 用途:
返回有关应用程序状态的信息。应用 具体。 论据: Key(字符串):要设置的键
值(字符串):为键设置的值 返回: 日志(字符串):调试或错误消息 用途:
设置应用程序选项。例如。键=“模式”,值=“mempool” 内存池连接,或 Key=“mode”,Value=“consensus” 共识连接。其他选项是特定于应用程序的。 论据: 验证器([]Validator):初始起源-validators 用途:
创世时被召唤一次 论据: 高度 (uint64):起始区块高度 用途:
表示新块的开始。在任何之前调用 追加 Txs。 论据: 高度 (uint64):结束的区块高度 返回: 验证器([]Validator):将 validators 更改为新的 投票权(0表示删除) 用途:
发出块结束的信号。毕竟在每次提交之前调用 交易 有关更多详细信息,请参阅 ABCI 存储库。发件人可能想要的原因有多种 接收链对数据包传送的确认。 例如,发送者可能不知道消息的状态 目标链(如果预计会出现故障)。或者,发件人可以 想要对数据包施加超时(使用 MaxHeight 数据包产量),而任何目标链都可能遭受拒绝服务攻击,传入数量突然激增 数据包。 在这些情况下,发件人可以要求送达确认 将初始数据包状态设置为 AckPending。那么,就是 接收链有责任通过包括 Merkle 应用程序中缩写为 IBCPacket hash。 首先,在“Hub”上发布 IBCBlockCommit 和 IBCPacketTx 这证明了“Zone1”上存在 IBCPacket。这么说 IBCPacketTx 具有以下值: FromChainID:“Zone1” FromBlockHeight : 100 (比如说) 数据包:IBC数据包:
标头:IBCPacketHeader: 源链ID:“Zone1” 目标链 ID:“Zone2” 数量:200(比如说) 状态:确认待处理 类型:“硬币” MaxHeight:350(假设“Hub”当前高度为 300) Payload : <“硬币”有效负载的字节> 接下来,在“Zone2”上发布 IBCBlockCommit 和 IBCPacketTx 这证明了“Hub”上存在IBCPacket。这么说 IBCPacketTx 具有以下值: FromChainID : “Hub” 从块高度:300 数据包: IBC 数据包: 标头:IBCPacketHeader: 源链ID:“Zone1” 目标链 ID:“Zone2” 数量:200 状态:确认待处理 类型:“硬币” 最大高度:350 有效负载:<“硬币”有效负载的相同字节> 接下来,“Zone2”必须在其应用程序-hash中包含一个缩写数据包 显示 AckSent 的新状态。 IBCBlockCommit 和 IBCPacketTx 被发布回“Hub”,证明存在 “Zone2”上的缩写IBCPacket。说 IBCPacketTx 具有以下值: FromChainID:“Zone2”
FromBlockHeight : 400 (比如说) 数据包: IBC 数据包: 标头:IBCPacketHeader: 源链ID:“Zone1” 目标链 ID:“Zone2” 数量:200 状态:已发送 类型:“硬币” 最大高度:350 PayloadHash : <同一“硬币”有效负载的 hash 字节> 最后,“集线器”必须更新数据包的状态 AckPending 到 AckReceived。这种新的分析状态的证据 应该回到“Zone2”。假设 IBCPacketTx 具有以下内容 值: FromChainID : “Hub” 从块高度:301 数据包: IBC 数据包: 标头:IBCPacketHeader: 源链ID:“Zone1” 目标链 ID:“Zone2” 数量:200 状态:已收到 类型:“硬币” 最大高度:350 PayloadHash : <同一“硬币”有效负载的 hash 字节> 同时,“Zone1”可能乐观地认为交付成功 除非有相反的证据证明是“硬币”包 “枢纽”。在上面的示例中,如果“Hub”未收到 AckSent
块 350 来自“Zone2”的状态,它会设置状态 自动超时。这个超时的证据可以得到 发回“Zone1”,并且可以返回任何 token。 支持两种类型的 Merkle tree Tendermint/Cosmos 生态系统:简单树和 IAVL+ 树。 简单树是一个静态元素列表的 Merkle tree 。如果 项目数不是 2 的幂,有些叶子将位于 不同的级别。简单树试图保持树的两侧 高度相同,但左侧可能更大。这个 Merkle tree 是 用于对区块的交易进行 Merkle 化,顶层 应用程序状态根的元素。IAVL+数据结构的目的是提供持久性 应用程序状态中键值对的存储,以便 可以有效地计算确定性 Merkle 根 hash。的 使用 AVL 算法的变体来平衡树,并且所有 操作是 O(log(n))。 在AVL树中,任意节点的两个子子树的高度 最多相差一。每当违反此条件时 更新时,通过创建 O(log(n)) 个新节点来重新平衡树 指向旧树中未修改的节点。在原来的AVL中 算法中,内部节点也可以保存键值对。 AVL+ 算法(注意加号)修改AVL算法以保留所有 叶节点上的值,而仅使用分支节点来存储键。 这简化了算法,同时保留了 Merkle hash 踪迹 短。 AVL+ 树类似于 Ethereum 的 Patricia 尝试。有 权衡。键在插入之前不需要 hashed IAVL+ 树,因此这可以在键中提供更快的有序迭代 空间可能有利于某些应用程序。逻辑更简单 实现,只需要两种类型的节点——内部节点和 叶节点。 Merkle 证明平均较短,是 * / \ / \ / \ / \ * * / \ / \ / \ / \ / \ / \ * * * h6 / \ / \ / \ h0 h1 h2 h3 h4 h5 具有 7 个元素的 SimpleTree
平衡二叉树。另一方面,默克尔根 IAVL+树取决于更新的顺序。 我们将支持额外的高效 Merkle tree,例如 当二进制变体变为 Ethereum 的 Patricia Trie 时 可用。 在规范的实现中,交易被流式传输到 Cosmos 集线器应用程序通过 ABCI 接口。 Cosmos Hub将接受一些主要交易 类型,包括 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) :提交的轮次 提交([]投票):>⅔ Tendermint 预提交投票表明 包含一个块提交 ValidatorsHash ([]byte) :新的 Merkle 树根 hash validator 设置
ValidatorsHashProof (SimpleProof):一个 SimpleTree Merkleproof,用于根据 BlockHash 证明 ValidatorsHash AppHash ([]byte) :IAVLTree Merkle 树根 hash 应用状态 AppHashProof (SimpleProof):SimpleTree Merkle 证明 对照 BlockHash 证明 AppHash IBC数据包由以下部分组成: 标头 (IBCPacketHeader) :数据包标头 Payload ([]byte) :数据包有效负载的字节。可选 PayloadHash ([]byte) :数据包字节的 hash 。 可选 Payload 或 PayloadHash 之一必须存在。 hash IBCPacket 的 是两个项目的简单 Merkle 根,即 Header 和有效负载。没有完整负载的 IBC 数据包称为 缩写数据包。 IBCPacketHeader 由以下部分组成: SrcChainID(字符串):源 blockchain ID DstChainID(字符串):目的地 blockchain ID Number(int):所有数据包的唯一编号 状态(枚举):可以是 AckPending 、 AckSent 之一, AckReceived 、 NoAck 或超时 类型(字符串):类型取决于应用程序。 Cosmos 保留“coin”数据包类型 MaxHeight (int) :如果状态不是 NoAckWanted 或 AckReceived 到了这个高度,状态就变成 Timeout 。可选 IBCPacketTx 交易由以下部分组成:FromChainID(字符串):blockchain 的 ID,即 提供此数据包;不一定是来源 FromBlockHeight (int) : blockchain 高度,其中 以下数据包包含(Merkle 化)在块 hash 中 源链 Packet (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”想要通过“Hub”向“Zone2”发送数据包时, 无论数据包在“Zone1”、“Hub”还是“Zone2”上进行 Merkleized,IBCPacket 数据都是相同的。唯一可变的yield是 跟踪递送的状态。 我们感谢我们的朋友和同行在概念化方面提供的帮助, 审查并为我们与 Tendermint 的合作提供支持 和 Cosmos。 IBC/<源链ID>/<目标链ID>/<编号>
SkuChain 的 Zaki Manian 在格式化和 措辞,特别是在 ABCI 部分下 Althea 的 Jehan Tremback 和达斯汀·拜因顿 (Dustin Byington) 提供的帮助 初始迭代 Honey Badger 的 Andrew Miller 对共识的反馈 Greg Slepak 对共识和措辞的反馈 还要感谢 Bill Gleim 和 Seunghwan Han 所做的各种努力 贡献。 此处提供您的姓名和组织以供您贡献 1 Bitcoin:https://bitcoin.org/bitcoin.pdf 2 零现金:http://zerocash-project.org/paper 3Ethereum:https://github.com/ethereum/wiki/wiki/WhitePaper 4DAO: 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/
13Stellar: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/ 17ABCI: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 nceAnalysisOfLibswift.pdf 20 个 DLS: 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
Ø è
Fikir Birliği ve Teknik Detaylar
İyi tasarlanmış bir fikir birliği protokolü bazı özellikleri sağlamalıdır. Tolerans kapasitesinin aşılması durumunda garantiler ve fikir birliği başarısız olur. Bu özellikle ekonomik açıdan gereklidir. Bizans davranışının önemli mali etkiye sahip olabileceği sistemler ödül. Bu türden en önemli garanti, fikir birliğine yol açan süreçlerin başarısız (yani protokol istemcilerinin farklı değerleri kabul etmesine neden oldu - bir çatal) kurallarına göre belirlenebilir ve cezalandırılabilir. protokol veya muhtemelen hukuk sistemi. Hukuk sistemi ne zaman güvenilmez veya çağrılması aşırı pahalı, validators olabilir katılmak için depozito yatırmaya zorlananlar ve Kötü niyetli davranışlar ortaya çıktığında mevduatlar iptal edilebilir veya kesilebilir. [10] algılandı. Bunun, çatallanmanın olağan bir olay olduğu Bitcoin'den farklı olduğunu unutmayın ağ eşzamansızlığı ve göndermenin olasılıksal doğası nedeniyle kısmi hash çarpışmalar. Çoğu durumda kötü niyetli bir çatal olduğundan eşzamansızlık nedeniyle çataldan ayırt edilemez, Bitcoin olamaz Örtülü olanlar dışında çatal sorumluluğunu güvenilir bir şekilde uygulayın Yetim durumdaki bir bloğun madenciliği için madencilerin ödediği fırsat maliyeti. Oylama aşamalarına PreVote ve PreCommit diyoruz. Bir oy şuna olabilir: belirli bir blok veya Nil için. >⅔ ÖnOylardan oluşan bir koleksiyona diyoruz aynı turdaki tek bir blok için bir Polka ve >⅔ koleksiyonu Aynı turda tek bir blok için Ön Taahhütler. >⅔ ise Aynı turda Nil için Ön Komite, bir sonrakine geçiyorlar yuvarlak. Protokoldeki katı determinizmin zayıf bir etki yarattığını unutmayın. Hatalı liderlerin tespit edilmesi gerektiğinden senkronizasyon varsayımı ve
atlandı. Böylece, validators bir süre bekler, TimeoutPropose, Ön Oy Vermeden Önce ve değeri TimeoutPropose her turda artar. İlerleme bir turun geri kalanı tamamen eşzamansızdır, bu nedenle ilerleme yalnızca validator ağın >⅔'ünden haber aldığında yapılır. Pratikte, süresiz olarak engellemek için son derece güçlü bir düşman gerekirdi zayıf eşzamanlılık varsayımı (uzlaşının başarısız olmasına neden olur) asla bir blok gerçekleştirin) ve bunu yapmak daha da fazla yapılabilir Her birinde TimeoutPropose'un rastgele değerlerini kullanarak zor validator. Ek bir dizi kısıtlama veya Kilitleme Kuralı, ağ sonunda her yükseklikte yalnızca bir blok işleyecektir. Herhangi biri Birden fazla bloğun işlenmesine neden olmaya yönelik kötü niyetli girişim Belirli bir yükseklikte tanımlanabilir. İlk olarak, bir blok için PreCommit o blok için bir Polka şeklinde gerekçeli olarak gelmelidir. validator zaten R_1 turunda bir blok PreCommit'e sahipse, o blokta kilitli olduklarını söylüyorlardı ve Polka da bu durumu haklı çıkarıyordu. R_2 turundaki yeni Ön Taahhüt, R_polka turunda gelmelidir burada R_1 < R_polka <= R_2. İkincisi, validator'ler Teklif Vermeli ve/veya kilitli oldukları bloğa ÖnOy verin. Birlikte bunlar koşullar, bir validator'nin olmadan Ön Taahhüt yapmamasını sağlar Gerekçe olarak yeterli delil ve validator'ler PreCommit zaten PreCommit'e delil olarak katkıda bulunamaz başka bir şey. Bu hem güvenliği hem de canlılığı sağlar. fikir birliği algoritması. Protokolün tüm ayrıntıları burada açıklanmaktadır. Alternatif bir zincirin (çatal) varlığı ≥⅓ anlamına geldiğinden TendermintPoS'ta tüm blok başlıklarını senkronize etme ihtiyacı ortadan kalkar. bağlı hisse kesilebilir. Tabii ki, kesme işlemi gerektirdiğinden Birisi bir çatalın kanıtını paylaşıyorsa, hafif istemciler saklamalıdır herhangi bir blok-hash gördüğünü taahhüt eder. Ayrıca hafif istemcilervalidator kümesinde yapılan değişikliklerle periyodik olarak senkronize kalabilir. uzun menzilli saldırılardan kaçınmak için (ancak diğer çözümler mümkün). Ethereum'ye benzer bir ruhla Tendermint, uygulamaların her bloğa global bir Merkle kökü hash gömerek kolayca izin verin Hesap bakiyeleri, değer gibi şeyler için doğrulanabilir durum sorguları bir sözleşmede saklanması veya harcanmamış bir işlemin varlığı uygulamanın niteliğine bağlı olarak çıktı. Yeterince dayanıklı bir yayın ağları koleksiyonu varsayarsak ve statik bir validator kümesi varsa, blockchain içindeki herhangi bir çatal tespit edildi ve rahatsız edici validator'lerin mevduatları kesildi. Bu Vitalik Buterin'in ilk olarak 2014'ün başlarında önerdiği yenilik, diğer proof-of-stake'nin tehlikede olmayan hiçbir şey sorunu kripto para birimleri (bkz. İlgili Çalışma). Ancak validator ayarlandığından beri orijinali uzun bir süre boyunca değiştirebilmelidir validators'nin tümü bağımsız hale gelebilir ve dolayısıyla hiçbir maliyete katlanmadan, oluşum bloğundan yeni bir zincir oluşturun artık kilitli mevduatları yok. Bu saldırı gerçekleşti Kısa Menzilli Saldırının aksine Uzun Menzilli Saldırı (LRA) olarak bilinir Şu anda bağlı olan validator'lerin menzil saldırısına neden olduğu Menzil Saldırısı çataldır ve bu nedenle cezalandırılabilir (çataldan sorumlu olduğu varsayılarak BFT Tendermint fikir birliği gibi bir algoritma). Uzun Menzilli Saldırılar genellikle proof-of-stake'ye kritik bir darbe olduğu düşünülür. Neyse ki LRA aşağıdaki şekilde hafifletilebilir. Öncelikle bir süreliğine validator borcunu çözebilir (böylece teminat depozitolarını geri alabilir) ve artık fikir birliğine katılmak için ücret kazanmıyoruz), depozito belirli bir süre devredilemez hale getirilmelidir "bağların çözülme dönemi" olarak bilinen ve haftalar veya aylar. İkincisi, hafif istemcinin güvende olması için ilk ağa bağlandığında yeni bir bloğu doğrulaması gerekir-hash güvenilir bir kaynağa veya tercihen birden fazla kaynağa karşı. Bu
duruma bazen “zayıf öznellik” adı verilir. Son olarak, güvende kalabilmesi için şu tarihteki en son validator ayarıyla senkronize edilmesi gerekir en az bağlanma süresinin uzunluğu kadar sıklıkta. Bu Hafif istemcinin validator'deki değişikliklerden haberdar olmasını sağlar validator'nin sermayesi serbest olduğundan ve dolayısıyla artık tehlikede, bu da müşteriyi kandırmasına izin verecek bir noktadan başlayarak yeni bloklar oluşturarak uzun menzilli bir saldırı bağlandığı yerin yüksekliği (yeterince kontrole sahip olduğu varsayılarak) ilk özel anahtarların çoğu). LRA'nın bu şekilde üstesinden gelinmesinin, proof-of-work orijinal güvenlik modeli. PoW'da, hafif bir istemcinin mevcut yükseklikle senkronize edilebileceğini varsaydı. her blok başlığında iş kanıtını işleyerek istediğiniz zaman güvenilir bir oluşum bloğu oluşturabilirsiniz. Ancak LRA'nın üstesinden gelmek için hafif bir istemcinin belli bir düzenlilikle çevrimiçi olmasını gerektirir validator kümesindeki değişiklikleri takip edin ve ilk kez çevrimiçi olduklarında kimlik doğrulama konusunda özellikle dikkatli olmaları gerekir ağdan güvenilir kaynaklara karşı duyduklarını. arasında elbette, bu ikinci gereksinim Bitcoin gereksinimine benzer; burada protokol ve yazılımın da güvenilir bir yerden alınması gerekir. kaynak. LRA'yı önlemeye yönelik yukarıdaki yöntem validators için çok uygundur ve Tendermint destekli bir blockchain'nin tam düğümleri çünkü bunlar düğümlerin ağa bağlı kalması amaçlanır. yöntem aynı zamanda hafif istemciler için de uygundur. ağ ile sık sık senkronize edin. Ancak hafif istemciler için internete sık erişime sahip olmaları beklenmemektedir veya blockchain ağı, üstesinden gelmek için başka bir çözüm daha kullanılabilir LRA. validator olmayan token sahipleri token'lerini şu şekilde gönderebilir: çok uzun bir çözülme süresine sahip teminat (örneğin çok daha uzun validators için ayrılma döneminden daha uzun) ve hafif istemcilere hizmet veriyor Geçerliliğin geçerliliğini doğrulamak için ikincil bir yöntemle ve geçmiş blok-hashes. Bu token'ler hesaba katılmasa da blockchain'in fikir birliğinin güvenliği, yine deHafif müşteriler için güçlü garantiler sağlayın. Geçmiş blok ise-hash sorgulama Ethereum'de destekleniyordu, herkes kendi tokens'yi özel olarak tasarlanmış bir smart contract içinde sağlayın ve sağlayın Ücretli tasdik hizmetleri, hafif istemci LRA güvenliği için etkili bir pazar oluşturuyor. Blok taahhüdünün tanımlanması nedeniyle herhangi bir ≥⅓ koalisyonu oylama gücü blockchain'yi fanzin kapanıp kapanmayarak durdurabilir oylarını yayınlıyorlar. Böyle bir koalisyon aynı zamanda sansür de yapabilir bunları içeren blokları reddederek belirli işlemleri işlemler, ancak bu önemli bir oranda sonuçlanacaktır hızı yavaşlatacak blok tekliflerinin reddedilmesi blockchain'nin blok taahhütlerinin artması, faydasını ve değerini azaltır. Kötü niyetli koalisyon aynı zamanda oyları damla damla yayınlayabilir. blockchain blok taahhütlerinin neredeyse durma noktasına gelmesi veya devreye girmesi için bu saldırıların herhangi bir kombinasyonu. Son olarak aşağıdakilere neden olabilir: blockchain çift imzalayarak veya kilitlemeyi ihlal ederek çatallanmaya kurallar. Eğer küresel çapta aktif bir düşman da işin içinde olsaydı, bu durum bölüşülebilirdi. ağı yanlış gibi görünebilecek şekilde Yavaşlamadan validators alt kümesi sorumluydu. bu değil sadece Tendermint'in bir sınırlaması, daha ziyade hepsinin bir sınırlaması Ağı potansiyel olarak bir kişi tarafından kontrol edilen konsensüs protokolleri aktif düşman Bu tür saldırılar için validators'nin bir alt kümesi bir yeniden düzenleme teklifini imzalamak için harici yollarla koordinasyon sağlamak bir çatal (ve bunun herhangi bir kanıtını) ve başlangıç alt kümesini seçer validators imzalarıyla birlikte. Böyle bir yeniden düzenleme teklifini imzalayan doğrulayıcılar, diğer tüm çatallardaki teminatlarından vazgeçer. Müşteriler şunları yapmalıdır: Yeniden düzenleme teklifindeki imzaları doğrulayın, her türlü kanıtı doğrulayın, ve bir karar verin veya son kullanıcıyı bir karara yönlendirin. için Örneğin, bir telefon cüzdanı uygulaması kullanıcıya bir güvenlik kodu sorabilir.
uyarı, buzdolabı herhangi bir yeniden düzenleme teklifini kabul edebilirken Orijinal validator'lerin +½'si tarafından oylama yetkisiyle imzalanmıştır. Hiçbir senkronize olmayan Bizans hataya dayanıklı algoritma gelemez Oylama gücünün ≥⅓'ü sahtekâr olduğunda fikir birliğine varmak, ancak yine de çatallanmak oylama gücünün ≥⅓'ünün halihazırda sahtekâr olduğunu varsayar gerekçesiz olarak çift imza veya kilit değiştirme. Yani imzalamak yeniden düzenleme teklifi çözülemeyecek bir koordinasyon sorunudur senkronize olmayan herhangi bir protokolle çözülür (ör. otomatik olarak ve güvenilirliği hakkında varsayımlarda bulunmadan temel ağ). Şimdilik, yeniden düzenleme önerisi koordinasyonu sorununu toplumsal uzlaşma yoluyla insan koordinasyonuna bırakıyoruz. internet medyasında. Doğrulayıcılar, orada olduğundan emin olmak için dikkatli olmalıdır. Çakışan iki yeniden düzenleme teklifinin imzalandığı durumları önlemek için, bir yeniden düzenleme teklifinin imzalanmasından önce kalan ağ bölümü yoktur. Harici koordinasyon ortamının ve protokolün sağlam, buradan çatalların sansürden daha az endişe verici olduğu sonucu çıkıyor saldırılar. ≥⅓ Bizans gerektiren çatal ve sansüre ek olarak oylama gücü, >⅔ oylama gücünden oluşan bir koalisyon taahhütte bulunabilir keyfi, geçersiz durum. Bu herhangi bir (BFT) özelliğidir Konsensüs sistemi. Çatal oluşturan çift imzalamanın aksine kolayca doğrulanabilir kanıtlarla, bir kişinin bağlılığını tespit etmek geçersiz durum, doğrulama yapmayan eşlerin tüm blokları doğrulamasını gerektirir, bu, durumun yerel bir kopyasını tuttukları ve yürüttükleri anlamına gelir Her işlem için durum kökünü bağımsız olarak hesaplayarak kendileri. Bir kez tespit edildiğinde böyle bir arızayla baş etmenin tek yolu toplumsal mutabakat yoluyla gerçekleşir. Örneğin, Bitcoin durumunda yazılım hataları nedeniyle çatallanma başarısız oldu (Mart ayında olduğu gibi) 2013) veya Bizans davranışından dolayı geçersiz bir durumun gerçekleştirilmesi Madenciler (Temmuz 2015'te olduğu gibi), iyi bağlantılara sahip bir topluluk işletmeler, geliştiriciler, madenciler ve diğer kuruluşlar manuel eylemlerin ne olduğu konusunda toplumsal bir fikir birliği oluşturduKatılımcıların ağı iyileştirmesi gerekiyor. Ayrıca, beri validators İhale blockchain olması beklenebilir tanımlanabilir, geçersiz bir durumun taahhüdü bile olabilir istenirse kanun veya bazı harici içtihatlar tarafından cezalandırılabilir. ABCI, şu adresten teslim edilen 3 ana mesaj türünden oluşur: uygulamanın çekirdeği. Uygulama şu şekilde yanıt verir: karşılık gelen yanıt mesajları. AppendTx mesajı uygulamanın çalışma atıdır. Her biri blockchain içindeki işlem bu mesajla iletilir. uygulamanın, alınan her işlemi doğrulaması gerekir. Mevcut duruma, uygulama protokolüne karşı AppendTx mesajı, ve işlemin kriptografik kimlik bilgileri. Doğrulanmış işlemin daha sonra uygulama durumunu güncellemesi gerekir - tarafından bir değeri anahtar değerler deposuna bağlamak veya UTXO değerini güncelleyerek veritabanı. CheckTx mesajı AppendTx'e benzer ancak yalnızca işlemlerin doğrulanması. Tendermint Core'un ilk bellek havuzu kontrolleri CheckTx ile yapılan bir işlemin geçerliliği ve yalnızca aktarmaların geçerli olması akranlarıyla işlem yapıyor. Uygulamalar artan bir değeri kontrol edebilir işlemde nonce ve eğer CheckTx'te bir hata döndürüyorsa nonce eski. Taahhüt mesajı bir şifreleme hesaplamak için kullanılır mevcut başvuru durumuna bağlılık, sonraki blok başlığı. Bunun bazı kullanışlı özellikleri var. Bu durumun güncellenmesindeki tutarsızlıklar artık şu şekilde görünecek: blockchain tüm programlama sınıfını yakalayan çatallar hatalar. Bu aynı zamanda güvenli hafifliğin geliştirilmesini de kolaylaştırır. Merkle-hash kanıtları kontrol edilerek doğrulanabildiği için istemciler blok-hash ve blok-hash yetersayı tarafından imzalandı validators (oy gücüne göre).
Ek ABCI mesajları uygulamanın takip etmesine olanak tanır ve validator kümesini değiştirin ve uygulamanın yükseklik ve taahhüt oyları gibi bilgileri bloke edin. ABCI istekler/yanıtlar basit Protobuf mesajlarıdır. Kontrol et şemayı çıkarın. Argümanlar: Veri ([]bayt): İstek işlemi baytları İade: Kod (uint32): Yanıt kodu Veri ([]bayt): Varsa sonuç baytları Günlük (dize): Hata ayıklama veya hata mesajı Kullanımı:
Bir işlem ekleyin ve çalıştırın. İşlem geçerli ise CodeType.OK değerini döndürür Argümanlar: Veri ([]bayt): İstek işlemi baytları İade: Kod (uint32): Yanıt kodu Veri ([]bayt): Varsa sonuç baytları Günlük (dize): Hata ayıklama veya hata mesajı Kullanımı:
Bir işlemi doğrulayın. Bu mesaj, devlet. İşlemler ilk önce CheckTx üzerinden gerçekleştirilir bellek katmanındaki eşlere yayınlanır. Yapabilirsin CheckTx yarı durumlu ve Taahhüt üzerine durumu temizler veya BeginBlock , bağımlı işlem dizilerine izin vermek için aynı blokta.
İade: Veri ([]bayt): Merkle kökü hash Günlük (dize): Hata ayıklama veya hata mesajı Kullanımı:
Uygulama durumunun Merkle kökünü hash döndürün. Argümanlar: Veri ([]bayt): Sorgu isteği baytları İade: Kod (uint32): Yanıt kodu Veri ([]bayt): Sorgu yanıtı baytları Günlük (dize): Hata ayıklama veya hata mesajı Kullanımı:
Yanıt kuyruğunu temizleyin. Gerçekleştiren uygulamalar type.Uygulamanın bu mesajı uygulamasına gerek yoktur; proje tarafından ele alınmaktadır. İade: Veri ([]bayt): Bilgi baytları Kullanımı:
Uygulama durumuyla ilgili bilgileri döndürün. Başvuru özel. Argümanlar: Anahtar (dize): Ayarlanacak anahtar
Değer (dize): Anahtar için ayarlanacak değer İade: Günlük (dize): Hata ayıklama veya hata mesajı Kullanımı:
Uygulama seçeneklerini ayarlayın. Örn. Anahtar=“mod”, Değer=“bellek havuzu” için bir bellek havuzu bağlantısı veya Anahtar=“mod”, Değer=“fikir birliği” fikir birliği bağlantısı. Diğer seçenekler uygulamaya özeldir. Argümanlar: Doğrulayıcılar ([]Doğrulayıcı): İlk oluşum-validators Kullanımı:
Bir zamanlar yaradılışta çağrıldı Argümanlar: Yükseklik (uint64): Başlangıç bloğunun yüksekliği Kullanımı:
Yeni bir bloğun başlangıcını işaret eder. Herhangi birinden önce çağrıldı Ek Tx'ler. Argümanlar: Yükseklik (uint64): Biten blok yüksekliği İade: Doğrulayıcılar ([]Doğrulayıcı): validators yenisiyle değiştirildi oylama yetkileri (kaldırmak için 0) Kullanımı:
Bir bloğun sonunu işaret eder. Sonuçta her Taahhütten önce çağrıldı işlemler Daha fazla ayrıntı için ABCI deposuna bakın.Bir göndericinin bu bilgiyi istemesinin birkaç nedeni vardır. Paketin tesliminin alıcı zincir tarafından onaylanması. Örneğin, gönderen e-postanın durumunu bilmiyor olabilir. Arızalı olması bekleniyorsa hedef zincir. Veya gönderen pakete bir zaman aşımı uygulamak istiyorsanız (MaxHeight ile) Paket sarımı), ancak herhangi bir hedef zincir, gelen paketlerin sayısında ani bir artışla hizmet reddi saldırılarına maruz kalabilir. paketler. Bu durumlarda gönderici teslimat onayını talep edebilir. başlangıç paket durumunu AckPending olarak ayarlayarak. O halde, bu teslimatı onaylamak için teslim alma zincirinin sorumluluğundadır. Merkle uygulamasında IBCPacket olarak kısaltılmıştır hash. İlk olarak, "Hub" üzerinde bir IBCBlockCommit ve IBCPacketTx yayınlanır. bu, "Bölge1"de bir IBCPaket 'in varlığını kanıtlar. Bunu söyle IBCPacketTx şu değere sahiptir: FromChainID : “Bölge1” FromBlockHeight: 100 (örneğin) Paket : bir IBCPaket :
Başlık: an IBCPacketHeader:
SrcChainID : “Bölge1”
DstChainID : “Bölge2”
Sayı: 200 (örneğin)
Durum : Onay Bekleniyor
Tür: “para”
MaxHeight : 350 (“Hub”ın şu anda 300 yükseklikte olduğunu söyleyin)
Yük :
FromBlockHeight: 400 (örneğin)
Paket : bir IBCPaket :
Başlık : an IBCPacketHeader :
SrcChainID : “Bölge1”
DstChainID : “Bölge2”
Sayı : 200
Durum: AlındıGönderildi
Tür: “para”
Maksimum Yükseklik : 350
PayloadHash :
durumu 350 bloğundaki “Bölge2”den ayarlasaydı, durumu ayarlardı otomatik olarak Zaman Aşımı'na geçer. Bu zaman aşımı kanıtı, “Bölge1”e geri gönderilir ve tüm token'ler iade edilebilir. Desteklenen iki tür Merkle trees vardır Tendermint/Cosmos ekosistemi: Basit Ağaç ve IAVL+ Ağaç. Basit Ağaç, statik bir öğe listesi için Merkle tree'dur. Eğer öğelerin sayısı ikinin katı değil, bazı yapraklar farklı seviyeler. Simple Tree, ağacın her iki tarafını da aynı seviyede tutmaya çalışır. aynı yükseklikte, ancak soldaki daha büyük olabilir. Bu Merkle tree Bir bloğun işlemlerini ve üst seviyeyi Merkle-ize etmek için kullanılır uygulama durumu kökünün öğeleri.IAVL+ veri yapısının amacı kalıcı uygulama durumundaki anahtar/değer çiftleri için depolama, öyle ki deterministik Merkle kökü hash verimli bir şekilde hesaplanabilir. ağaç, AVL algoritmasının bir çeşidi kullanılarak dengelenir ve tümü işlemler O(log(n))'dir. Bir AVL ağacında herhangi bir düğümün iki alt alt ağacının yükseklikleri en fazla bir farklılık gösterir. Bu koşul herhangi bir şekilde ihlal edildiğinde güncelleme, ağaç O(log(n)) yeni düğümler oluşturularak yeniden dengelenir eski ağacın değiştirilmemiş düğümlerine işaret eder. Orijinal AVL'de Algoritmaya göre iç düğümler aynı zamanda anahtar/değer çiftlerini de tutabilir. AVL+ algoritma (artıya dikkat edin) tümünü koruyacak şekilde AVL algoritmasını değiştirir anahtarları depolamak için yalnızca dal düğümlerini kullanırken, yaprak düğümlerdeki değerler. Bu, merkle hash izini korurken algoritmayı basitleştirir kısa. AVL+ Ağacı, Ethereum'nin Patricia denemelerine benzer. var ödünleşimler. Anahtarların eklenmeden önce hashed edilmesi gerekmez IAVL+ ağaçları, böylece anahtarda daha hızlı sıralı yineleme sağlar bazı uygulamalara fayda sağlayabilecek alan. Mantık daha basit yalnızca iki tür düğüm gerektiren uygulama; iç düğümler ve yaprak düğümleri. Merkle kanıtı ortalama olarak daha kısadır; * / \ / \ / \ / \ * * / \ / \ / \ / \ / \ / \ * * * h6 / \ / \ / \ h0 h1 h2 h3 h4 h5 7 öğeli bir SimpleTree
dengeli ikili ağaç Öte yandan, bir sayının Merkle kökü IAVL+ ağacı güncellemelerin sırasına bağlıdır. Ek verimli Merkle tree'leri destekleyeceğiz, örneğin Ethereum’den Patricia Trie ikili değişken haline geldiğinde mevcut. Kanonik uygulamada, işlemler şu adrese aktarılır: ABCI arayüzü aracılığıyla Cosmos hub uygulaması. Cosmos Hub bir dizi birincil işlemi kabul edecektir SendTx , BondTx , UnbondTx , ReportHackTx dahil olmak üzere türler, SlashTx , BurnAtomTx , ProposalCreateTx ve ProposalVoteTx , bunlar oldukça açıklayıcıdır ve bir belgede belgelenecektir. Bu makalenin gelecekteki revizyonu. Burada iki birincil belgeyi belgeliyoruz IBC için işlem türleri: IBCBlockCommitTx ve IBCPacketTx. Bir IBCBlockCommitTx işlemi şunlardan oluşur: ChainID (string) : blockchain'nin kimliği BlockHash ([]byte) : Block-hash bayt, Merkle kökü bu uygulamayı içerir-hash BlockPartsHeader (PartSetHeader) : Blok parça kümesi başlığı bayt, yalnızca oy imzalarını doğrulamak için gerekli BlockHeight (int) : Taahhüdün yüksekliği BlockRound (int) : Taahhüt turu Taahhüt ([]Oy): >⅔ Tendermint Ön Taahhüdü şunu oylar: bir blok taahhüdünü içerir ValidatorsHash ([]byte) : Yeninin Merkle ağacı kökü hash validator ayarlandı
ValidatorsHashProof (SimpleProof): ValidatorsHash'in BlockHash'e karşı kanıtlanması için SimpleTree Merkleproof
AppHash ([]byte) : IAVLTree Merkle ağacı kökü hash
uygulama durumu
AppHashProof (SimpleProof): SimpleTree Merkle'ye karşı dayanıklı
AppHash'in BlockHash'a karşı kanıtlanması
Bir IBCPaket aşağıdakilerden oluşur:
Başlık (IBCPacketHeader): Paket başlığı
Yük ([]bayt): Paket yükünün baytları. İsteğe bağlı
PayloadHash ([]byte) : Paketin baytları için hash.
İsteğe bağlı
Payload veya PayloadHash'tan birinin mevcut olması gerekir. hash
IBCPaket 'in iki öğesi olan Başlık'ın basit Merkle köküdür
ve Yük . Tam yük taşımayan bir IBCPakete adı verilir
kısaltılmış paket
Bir IBCPacketHeader aşağıdakilerden oluşur:
SrcChainID (string) : Kaynak blockchain kimliği
DstChainID (string): Hedef blockchain kimliği
Sayı (int): Tüm paketler için benzersiz bir sayı
Durum (numaralandırma): AckPending , AckSent ,'den biri olabilir
AckReceived, NoAck veya Zaman Aşımı
Tür (dize): Türler uygulamaya bağlıdır. Cosmos
"jeton" paket türünü saklı tutar
MaxHeight (int): Durum NoAckWanted veya AckReceived değilse
bu yüksekliğe göre durum Timeout olur. İsteğe bağlı
Bir IBCPacketTx işlemi şunlardan oluşur:FromChainID (string) : blockchain'nın kimliği:
bu paketi sağlamak; mutlaka kaynak değil
FromBlockHeight (int) : blockchain yüksekliği
Aşağıdaki paket, hash bloğuna dahil edilmiştir (Merkle-ized)
kaynak zinciri
Paket (IBCPacket): Durumu bir olabilecek bir veri paketi
AckPending , AckSent , AckReceived , NoAck veya Timeout'un sayısı
PacketProof (IAVLProof): Kanıtlama için IAVLTree Merkle geçirmez
paketin hash kaynak zincirinin AppHash'ine karşı
verilen yükseklik
“Bölge1”den “Bölge2”ye paket gönderme sırası
"Hub" aracılığıyla geçiş {Şekil X}'te gösterilmektedir. İlk olarak bir IBCPacketTx
"Hub"a paketin uygulama durumuna dahil olduğunu kanıtlar
“Bölge1”. Daha sonra başka bir IBCPacketTx "Bölge2"ye şunu kanıtlar:
paket “Hub”un uygulama durumuna dahil edilir. Bu sırada
prosedür, IBCPacket verileri aynıdır: SrcChainID
her zaman “Bölge1”dir ve DstChainID her zaman "Bölge2"dir.
PacketProof doğru Merkle geçirmez yola sahip olmalıdır.
şöyle:
“Bölge1” “Hub” üzerinden “Bölge2”ye paket göndermek istediğinde,
IBCPaket verileri, paketin "Bölge1", "Hub" veya "Bölge2"de Merkleleştirilmiş olmasına bakılmaksızın aynıdır. Değişebilen tek sarı
Teslimatı takip etme durumu.
Kavramsallaştırmada yardım eden arkadaşlarımıza ve akranlarımıza teşekkür ederiz.
Tendermint ile yaptığımız çalışmaları gözden geçirmek ve destek sağlamak
ve Cosmos.
IBC/
SkuChain'den Zaki Manian, biçimlendirme konusunda çok yardımcı oldu ve özellikle ABCI bölümü altındaki ifadeler Althea'dan Jehan Tremback ve Dustin Byington'a yardımlarından dolayı ilk yinelemeler Honey Badger'dan Andrew Miller'a fikir birliğiyle ilgili geri bildirimleri için teşekkür ederiz Greg Slepak'a fikir birliği ve ifadelerle ilgili geribildirim için teşekkür ederiz. Ayrıca çeşitli katkılarından dolayı Bill Gleim ve Seunghwan Han'a teşekkürler. katkılar. Adınız ve kuruluşunuz katkılarınız için burada 1 Bitcoin: https://bitcoin.org/bitcoin.pdf 2 ZeroCash: http://zerocash-project.org/paper 3 Ethereum: https://github.com/ethereum/wiki/wiki/WhitePaper 4DAO: https://download.slock.it/public/DAO/WhitePaper.pdf 5 Ayrılmış Tanık: https://github.com/bitcoin/bips/blob/master/bip0141.mediawiki 6 BitcoinNG: https://arxiv.org/pdf/1510.02037v2.pdf 7 Yıldırım Ağı: https://lightning.network/lightningnetwork-paper-DRAFT-0.5.pdf 8 İhale: https://github.com/tendermint/tendermint/wiki 9 FLP İmkansızlığı: https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf 10 Kesici: https://blog.ethereum.org/2014/01/15/slasher-apunitive-proof-of-stake-algorithm/ 11 PBFT: http://pmg.csail.mit.edu/papers/osdi99.pdf 12 BitShares: https://bitshares.org/technology/delegatedproof-of-stake-consensus/
13 Stellar: https://www.stellar.org/papers/stellar-consensusprotocol.pdf 14 Interledger: https://interledger.org/rfcs/0001-interledgerarchitecture/ 15 Yan Zincir: https://blockstream.com/sidechains.pdf 16 Casper: https://blog.ethereum.org/2015/08/01/introducing-casperfriendly-ghost/ 17 ABCI: https://github.com/tendermint/abci 18 Ethereum Parçalama: https://github.com/ethereum/EIPs/issues/53 19 LibSwift: http://www.ds.ewi.tudelft.nl/yleadmin/pds/papers/Performa nceAnalizOfLibswift.pdf 20 DLS: http://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf 21 İnce İstemci Güvenliği: https://en.bitcoin.it/wiki/Thin_Client_Security 22 Ethereum 2.0 Leylak Rengi Kağıt: http://vitalik.ca/yles/mauve_paper.html https://www.docdroid.net/ec7xGzs/314477721-ethereumplatform-review-opportunities-and-challenges-for-privateand-consortium-blockchains.pdf.html
3 e