Cosmos 基础教程（一） -- 不可不知的开发术语

最新推荐文章于 2024-05-12 09:31:46 发布

chinusyan

最新推荐文章于 2024-05-12 09:31:46 发布

阅读量1.5k

点赞数

分类专栏：区块链文章标签：区块链 Cosmos

本文链接：https://blog.csdn.net/chinus_yan/article/details/129031776

版权

区块链专栏收录该内容

17 篇文章 1 订阅

订阅专栏

CometBFT

DOC

您可以在本节中找到几个技术术语的概述，包括每个术语的解释和进一步资源的链接——在使用Cosmos SDK进行开发时，所有这些都是必不可少的。

在本节中，您将了解以下术语:

Cosmos and Interchain
LCD
RPC
Protobuf -协议缓冲区
gRPC, gRPC-web和gRPC- gateway
Amino

所有这些术语都与如何在Cosmos SDK区块链中进行节点交互有关。

一、Cosmos and Interchain

Cosmos指的是特定于应用程序的区块链网络，由链间（Interchain ）栈构建，并通过区块链间通信协议(Inter-Blockchain Communication Protocol，IBC)相互连接。然而，Cosmos 将很快被称为 Interchain。术语“Cosmos”、“Cosmos 生态系统(Cosmos Ecosystem)”和“ Interchain ”可以理解为同义词。

二、Interchain 栈

Interchain 开发人员可用的各种工具可以统称为 Interchain 栈。

Tools within the Interchain Stack, which contain “Cosmos” in their name will remain unchanged by current terminology changes, such as the Cosmos SDK and CosmWasm. Any chain built with the Cosmos SDK can typically be referred to as “a Cosmos chain” or “appchain”.

名称中包含“Cosmos”的Interchain Stack中的工具将不会因当前的术语变化而改变，例如 Cosmos SDK 和 CosmWasm。任何使用Cosmos SDK构建的链都可以被称为“Cosmos链”或“应用链(appchain)”。

三、Cosmos Hub

Cosmos Hub是一个链，作为 Interchain 的经济中心和其他 Cosmos链的服务提供商。该中心使用Interchain Stack构建，是ATOM令牌、链间安全（Interchain Security）以及Cosmos SDK、Tendermint和IBC构建器的所在地。

四、Light client daemon (LCD)

与完整节点相比，轻客户端（light client）只跟踪区块链上的某些信息片段。轻客户端不跟踪区块链的整个状态，也不包含链的每个交易/区块。

在Tendermint的共识中，轻客户端协议允许客户端受益于完整节点受益的相同程度的安全，同时带宽需求被最小化。客户端可以接收区块链状态和事务的加密证明，而无需同步所有块甚至它们的头。

查看Ethan Frey在Tendermint共识中的轻客户端(打开新窗口)，了解更多关于轻客户端如何在Tendermint共识中使用的信息。

因此，轻客户端对于区块链间通信协议(IBC)如何跟踪时间戳、根哈希和下一个验证器集哈希等信息也至关重要。这节省了空间并提高了状态更新处理的效率。

light client daemon (LCD)是Cosmos SDK公开的HTTP1.1服务器，其默认端口是1317。它为链公开了一个REST API，这意味着一个 representational state transfer应用程序编程接口——这个API允许与RESTful web服务进行交互。传统上，每个查询都为LCD重新实现，并在幕后路由到RPC。

为什么称为 light client daemon(LCD)？
在SDK v0.40之前，要获得REST API，必须打开新窗口运行另一个后端服务(或 daemon，一个继承自Unix的术语)，例如使用gaiacli rest-server --laddr 0.0.0.0:1317 --node localhost:26657。在Cosmos SDK v0.40中，REST被移动到节点服务(node service)中，使其成为Cosmos SDK的一部分，但术语“daemon”仍然存在，导致了light client daemon(LCD)的名称。

五、Remote procedure call (RPC)

远程过程调用(emote procedure call，RPC)是一种软件通信协议。这个术语经常出现在分布式计算中，因为RPC是一种实现进程间通信(IPC)的技术，它允许程序在不同的地址空间(不同的机器)中执行子例程过程。

RPC可以理解为客户端-服务器交互，其中“调用者”是客户端，更具体地说是请求程序，而“执行者”是服务器，更具体地说是提供服务的程序。交互是通过请求-响应消息传递系统（request-response message-passing）实现的。

简而言之，RPC是一种请求-响应协议，由客户机向远程服务器发送请求以执行子例程发起。

RPC允许调用不同的地址空间的函数。通常，被调用的函数在与调用它们的计算机不同的计算机上运行。然而，使用RPC，开发人员编码时就好像子例程是本地的一样;开发人员不必为远程交互编写详细的代码。因此，使用RPC意味着所有的调用过程基本上是相同的，不管它们是本地调用还是远程调用。

由于RPCs 实现了远程请求-响应协议，需要注意的是，如果出现网络问题，远程过程调用可能会失败。

六、RPC请求是如何工作的?

通常，当调用远程过程调用时，**过程参数（procedure parameters）**将通过网络传输到执行过程的执行环境。一旦完成，被调用的过程调用的结果将被转移到调用环境。然后在调用环境中恢复执行，就像在常规的本地过程调用中一样。

一个循序渐进的RPC请求可能如下所示:

客户端调用客户机存根——一段转换参数的代码，该代码在RPC期间在客户端和服务器之间传递。该调用是一个本地过程调用。

存根是代替较长程序的小程序例程。这使得机器的行为就像远程机器上的程序在本地操作一样。客户端有一个与远程过程接口的存根，而服务器有一个与原始请求过程接口的存根。
在RPC中，客户端存根替代了提供请求过程的程序。存根接受并将请求转发给远程过程。一旦远程过程完成请求，它将结果返回给存根，而存根又将结果传递给请求过程。
服务器还有一个与远程过程接口的存根。

客户端存根将过程参数打包到消息中。

Packing procedure parameters is called marshaling.

打包（Packing）过程参数称为封送处理（marshaling）。
具体来说，这是从一个或多个应用程序收集数据、将数据块放入消息缓冲区以及将数据组织成规定的数据格式的过程。
封送处理对于将用一种语言编写的程序的输出参数作为输入传递给用另一种语言编写的程序至关重要。

客户端存根然后发出一个系统调用来发送消息。
客户端的本地操作系统(OS)通过相应的传输层将消息从客户端(机器A)发送到服务器(机器B)。
服务器操作系统将传入的数据包传递给服务器存根。
服务器存根将消息及其所包含的过程参数解包(unpacks )——这称为解封送（unmarshaling）。
服务器存根调用服务器过程并执行该过程。
一旦过程完成，输出就返回到服务器存根。
服务器存根将返回值打包到消息中。
消息被发送到传输层，传输层将消息发送到客户端的传输层。
客户端存根对返回参数进行解封送，并将它们返回给原始调用客户端。

七、RPC and Cosmos

在Cosmos中，命令行界面(CLI)以及其他使用 RPCs 访问链。一个节点公开几个端点——gRPC、REST和Tendermint 端点（Tendermint endpoint）。

由Tendermint公开的Tendermint RPC端点是一个HTTP1.1服务器。默认端口号为 26657。gRPC服务器的默认端口为9090,REST服务器的默认端口为1317。Tendermint RPC独立于Cosmos SDK，可以进行配置。它使用HTTP POST和JSON-RPC 2.0进行数据编码。

有关Tendermint RPC、gRPC和REST服务器的更多信息，建议仔细查看Cosmos SDK文档。

Cosmos暴露了Tendermint RPC 和 Cosmos LCD。例如，CosmJS使用RPC来实现JSON-RPC API。

八、Protobuf

Protobuf(Protocol Buffers, 即“协议缓冲区”)是谷歌开发的一种开源、跨平台的数据格式。它帮助序列化结构化数据，并帮助网络中的程序通信或存储数据。

如果你想学习 Protobuf，看看官方文档可以帮助你深入了解，并提供指南和教程。
也可以看看关于这个平台上Protobuf的部分。

在Cosmos中，Protobuf是开发人员用来描述消息格式的数据序列化方法。在Cosmos应用程序中有很多内部通信，而Protobuf是如何完成通信的核心。

随着Cosmos SDK v0.40, Protobuf开始取代Amino作为链状态和交易的数据编码格式，部分原因是Protobuf的编码/解码性能比Amino更好。此外，开发人员工具也更适合Protobuf。切换的另一个好处是促进了gRPC的使用，因为Protobuf自动定义和生成gRPC函数。因此，开发人员不再需要为RPC、LCD和CLI实现相同的查询。

九、gRPC

gRPC是一个开源、高性能的远程过程调用(RPC)框架。它由谷歌开发用于处理rpc，并于2016年发布。gRPC可以在任何环境中运行，并支持多种编程语言。

有关gRPC的更多信息和非常有用的入门信息，请参阅gRPC文档

gRPC使用HTTP2进行传输，使用协议缓冲区(Protobuf)对数据进行编码。gRPC有一个单一的规范，这使得所有的gRPC实现一致。

十、gRPC and Cosmos

在 Cosmos 中，gRPCs 是使用Protobuf提供服务的传输控制协议(TCP) ，也用于数据编码。默认端口号为9090。

传输控制协议(TCP)是一种主要的互联网协议，它允许在客户端和服务器之间建立连接以发送数据。TCP使应用程序与internet协议(IP)之间的通信成为可能。

在Cosmos SDK中，Protobuf是主要的编码(encoding )库。

在Cosmos SDK中的编码
连线编码协议(wire encoding protocol)是定义数据如何从一点传输到另一点的协议。连线协议（Wire protocols）描述了在应用程序级别交换信息的方式。因此它是应用层协议中的通信协议，而不是传输协议。为了定义数据交换，连线协议需要以下特定属性:

Data types（数据类型） – 数据单位、消息格式等。
Communication endpoints （通信端点）
Capabilities （能力）——交付保证、沟通方向等等。
有线协议可以是基于文本的协议，也可以是二进制协议。

在Cosmos SDK中，有两类二进制连线编码类型（binary wire encoding types）:客户端编码和存储编码。客户端编码处理的是交易处理和交易签名，而存储编码处理的是状态机交易以及Merkle树中存储的内容。
Cosmos SDK使用两种二进制连线编码协议:
Amino: 一个对象编码规范。每个Cosmos SDK模块都使用氨基编解码器来序列化类型和接口。
协议缓冲区(Protocol Buffers，Protobuf):一种数据序列化方法，开发人员使用它来描述消息格式。
由于诸如性能缺陷和缺乏跨语言/客户端支持等原因，协议缓冲区比氨基越来越多地使用。

有关Cosmos SDK中编码的更多信息，请参考 Cosmos SDK documentation

十一、gRPC-web

gRPC支持不同的软件和硬件平台。gRPC-web是针对浏览器客户端的gRPC的JavaScript实现。gRPC-web客户端通过一个特殊的代理连接到gRPC服务。

关于gRPC-web的更多信息，建议仔细查看gRPC存储库。
要深入研究如何使用gRPC-web进行开发，文档的快速入门和基础教程是非常有价值的资源。

与一般的gRPC一样，gRPC-web使用带有Protobuf的HTTP2进行数据编码。默认端口号为9091。

Secret.js is a JavaScript SDK used to write applications interacting with the Secret Network, which uses gRPC-web.

十二、gRPC-gateway

gRPC-gateway是一种将gRPC端点公开为REST端点的工具。它帮助提供 RESTful 风格的APIs，读取gRPC服务定义并生成反向代理服务器，可以将RESTful JSON API转换为gRPC。对于Protobuf Query服务中定义的每个gRPC端点，Cosmos SDK提供了相应的REST端点。

gRPC- gateway的目标是“为您的gRPC服务提供HTTP+JSON接口”。有了它，开发人员可以从gRPC 的所有优势中受益，同时，仍然提供一个 RESTful API——例如，当你想开发一个 web 应用程序，但浏览器不支持 HTTP2 时，这是一个非常有用的工具。这有助于确保向后兼容性和多语言、多客户端支持。