JSON-RPC

去中心化应用程序（DApp）的常见设计不仅依赖于以太坊区块链，还依赖于API层。在这种情况下，DApp通过用户的以太坊帐户与智能合约进行交互，并通过交换用户凭据而发布的JWT token与API层进行交互。 目标是 使用以太坊帐户作为用户凭据 来请求JWT Token。 最简单的方法可能是请求用户使用其他随机生成的数据在以太坊上进行交易，然后在发出JWT之前检查交易和随机数据。这种方法有几个副作用： 1.用户必须进行交易并支付gas以进行简单的身份验证。 2.用户必须等待12-120秒（基于耗费的gas）才能完成身份验证过程。 3.每个用户的所有登录操作在以太坊区块链上变得不可公开。 这种方式不实用，并且有一些用户体验限制，我们需要一种方法让用户证明他拥有与他想要用来登录的帐户相关的私钥，而不是只（当然）要求私钥，而不管他是否进行交易。 解决方案 Metamask团队成员 Dan Finlay 的 这篇文章 向我启发了本教程。基本上，你的DApp可以提示用户使用他的私钥对短信进行签名。此签名操作不会生成交易，并且它由Metamask附加组件透明地处理（顺便说一句，你的帐户需要解锁）。签名后，帐户，消息和签名将发送到API Token endpoint。验证方法首先通过接受签名和明文消息作为输入的函数从签名中推断帐户（也称为公钥）。如果计算的以太坊地址等于用户提供的帐户

如果我们希望构造一个去中心化应用（DApp），除了智能合约的开发， 通常还需要使用其他开发语言为用户提供操作智能合约的用户接口，例如 开发一个网页、一个手机App或者一个桌面应用。这些代码都需要与以太坊 进行交互。 以太坊规定了每个节点需要实现的JSON RPC API 应用开发接口，该接口是传输无关的，应用程序可以通过HTTP、websocket或IPC等多种 通信机制来使用该接口协议操作以太坊节点： 理论上你可以使用任何语言基于JSON RPC接口开发出以太坊之上的 去中心化应用，不过为了提高开发效率，更好的办法是 使用特定语言的JSON RPC封装库，这些库封装了JSON RPC的协议细节， 有助于开发人员聚焦在业务逻辑的实现上。 Nethereum是以太坊官方推荐的.Net开发包，用于支持在.Net应用中访问 以太坊。在本课程中，我们将主要基于Nethereum开发包，使用C#语言来开发支持以太坊的.Net应用。 本课程的目的是帮助.Net工程师快速掌握开发以太坊应用的技能，同时穿插 讲解以太坊的一些核心概念，例如：账户、交易和智能合约等。 1.Hi,以太坊 这一章将通过一个简单的.Net应用的开发来讲解使用 C#进行以太坊应用开发的最简流程，通过这一部分的学习，你就可以在自己 的.Net应用中引入基本的以太坊支持了。 2.账户管理 这一章将详细介绍以太坊的账户管理接口

本文面向以太坊智能合约应用程序开发人员，并讨论如何在密码保护后，安全地运行你的以太坊节点，以便通过Internet进行安全输出。 Go Ethereum（geth）是以太坊节点最受欢迎的软件。其他流行的以太坊实现是Parity和cpp-ethereum等。分布式应用程序（Dapps）是JavaScript编码的网页，通过JSON-RPC API协议连接到任何这些以太坊节点软件，该协议是在HTTP协议之上自行运行的。 geth或没有节点软件本身不提供安全网络。将Ethereum JSON-RPC API暴露给公共Internet是不安全的，因为即使禁用私有API，这也会为琐碎的拒绝服务攻击打开一扇门。节点软件本身不需要提供安全的网络原语，因为这种内置功能会增加复杂性并为关键区块链节点软件增加攻击面。 Dapps本身是纯客户端HTML和JavaScript，不需要任何服务器，它们可以在任何Web浏览器中运行，包括移动和嵌入式浏览器，如Mist钱包内的一个。 使用Nginx代理作为HTTP基本身份验证器 有几种方法可以保护对HTTP API的访问。最常见的方法包括HTTP头中的API令牌，基于cookie的身份验证或 HTTP基本访问身份验证 。 HTTP基本身份验证是HTTP协议的一个非常古老的功能，其中Web浏览器打开一个本机弹出对话框，询问用户名和密码。它本质上的保护是有限的

以太坊应用开发接口指的是以太坊节点软件提供的API接口，去中心化应用可以利用这个接口访问以太坊上的智能合约。以太坊应用开发接口采用JSON-PRC标准，通常是通过HTTP或websocket提供给应用程序调用。 JSON-RPC是一种无状态轻量级远程过程调用（RPC）协议，规范定义了数据结构及相应的处理规则,规范使用JSON（RFC 4627）数据格式，规范本身是传输无关的，可以用于进程内通信、socket套接字、HTTP 或各种消息通信环境。 以太坊应用开发接口的配置 不同节点软件的应用开发接口访问点可能有所区别。常见以太坊节点软件的的默认JSON-RPC端结点如下： Geth - http://localhost:8545 Parity - http://localhost:8545 Pytheapp - http://localhost:4000 以最常见的geth节点软件为例，可以使用--rpc选项启动其基于HTTP的JSON-RPC应用开发接口。 ~$ geth --rpc 可以使用--rpcaddr和--rpcport选项修改默认的监听端口(8545)和监听地址(localhost)： ~$ geth --rpc --rpcaddr <ip> --rpcport <portnumber> 如果需要从浏览器中访问RPC接口，需要正确设置CORS，否则由于同源策略的限制

I'm trying to chose between REST and JSON-RPC for developing an API for a web application. Which one is easier to use for API clients? Update 2015: I have found REST easier to develop and use for an API which is served on Web/HTTP, because the existing and mature HTTP protocol which is understood by both client and server can be leveraged by the API. For example response codes, headers, queries, post bodies, caching and many other features can be used by the API without any additional effort or setup. ioseb The fundamental problem with RPC is coupling. RPC clients become tightly coupled to

EOS的是Block.One主导研发的一个区块链底层公链系统，它专门为支撑商业去中心化 应用（Decentralized Application）而设计，其代码开源。 比特币被称为区块链1.0，因为它开辟了数字加密货币的天下，走出了从0到1的决定性一步。 以太坊被称为区块链2.0，因为它提供了可运行智能合约的图灵完备的虚拟机，带来了无限的可能性。 而EOS则被称为区块链3.0，为什么？ 两个字： 性能 。 EOS的定位正是其首页的口号： 英文：The most powerful infrastructure for decentralized applications。 中文：最强大的去中心化应用基础设施。 EOS期望做加强版的以太坊，一个高吞吐量的智能合约平台。 以太坊虽然功能齐备，但受制于其设计选择，15秒的出块速度导致交易吞吐量 远远不能达到大规模实用的程度，大约只有30~40TPS（交易/秒）。而EOS则选择了不同的技术路线，目标是达到可观的百万TPS——考虑到Visa实际的处理速度才1700TPS，这一目标的确相当诱人。 EOS的共识机制 比特币和以太坊之所以吞吐量这么低，是受制于其设想的应用场景以及针对该场景所选择的共识机制——这两者都假设系统运行的环境完全不可信，因此都采用了工作量证明（Proof of Work）这种共识机制。 共识，顾名思义