区块链学习第三期

发表于 更新于 分类于 Changyan：

myBlog

合约和网络知识

[toc] ---

绪论:在深入学习区块链的过程中，越来越觉得区块链不是一个简简单单的数据库了，它建立的可编程系统如果真正能运用在社会基层，那将解决许多的问题。例如：农民工工资被拖欠，如果一开始老板就将工资打入智能合约，当农民工完成后，这个钱自动的就打向农民工钱包。

receive 接收以太函数

  • 一个合约最多有一个 receive 函数, 声明函数为： receive() external payable { … }
  • 不需要 function 关键字，也没有参数和返回值并且必须是　external　可见性和　payable 修饰． 它可以是 virtual 的，可以被重载也可以有 修改器modifier 。
  • 在对合约没有任何附加数据调用（通常是对合约转账）是会执行 receive 函数．　例如　通过 .send() or .transfer() 如果 receive 函数不存在，　但是有payable　的 fallback 回退函数fallback 回退函数fallback 回退函数 那么在进行纯以太转账时，fallback 函数会调用．
  • 如果两个函数都没有，这个合约就没法通过常规的转账交易接收以太（会抛出异常）．
  • 更糟的是，receive 函数可能只有 2300 gas 可以使用（如，当使用 send 或 transfer 时）， 除了基础的日志输出之外，进行其他操作的余地很小。

Fallback 回退函数

  • 合约可以最多有一个回退函数。函数声明为： fallback () external [payable] 或 fallback (bytes calldata _input) external [payable] returns (bytes memory _output)
  • 没有　function　关键字。　必须是　external　可见性，它可以是 virtual 的，可以被重载也可以有 修改器modifier 。
  • 如果在一个对合约调用中，没有其他函数与给定的函数标识符匹配fallback会被调用． 或者在没有 receive 函数
    　时，而没有提供附加数据对合约调用，那么fallback 函数会被执行。
  • fallback　函数始终会接收数据，但为了同时接收以太时，必须标记为　payable 。
  • 如果使用了带参数的版本，_input 将包含发送到合约的完整数据（等于 msg.data ），并且通过 _output 返回数据。 返回数据不是 ABI 编码过的数据，相反，它返回不经过修改的数据。
  • 更糟的是，如果回退函数在接收以太时调用，可能只有 2300 gas 可以使用，参考　receive接收函数
    与任何其他函数一样，只要有足够的 gas 传递给它，回退函数就可以执行复杂的操作。

竟然难度值取决于多少个0，那为什么不记录256个数字，数字是由 从一个0到256个0 组成的，挖矿的时候只需要按照难度值把这个随机数填进去就可以了

智能合约与DApp的关系与区别

以太坊社区把基于智能合约的应用称为去中心化的应用程序（Decentralized App，简称DApp)。DApp的目标是（或者应该是）让智能合约有一个友好的界面，外加一些额外的东西，例如IPFS(可以存储和读取数据的去中心化网络，不是出自以太坊团队，但有类似的精神）。DApp可以在一台与以太坊节点交互的中心化服务器上运行，也可以在任意一个以太坊平等节点上运行。

提示:与一般的网站不同，DApp不能在普通的服务器上运行。它需要提交交易到区块链并且从区块链而不是中心化数据库读取重要数据。相对于典型的用户登录系统，用户有可能被表示成一个“钱包”地址而其他用户数据保存在本地。许多事情都会与目前的Web应用有着不同的架构。

DApp流程如下。

  1. 用Solidity(或其他语言）编写智能合约（后缀为.sol)。

  2. 用sole编译器将.sol合约编译成EVM字节码。

  3. 编译好的字节码回送给DApp前端。

  4. 前端将编译好的智能合约部署到区块链中。

  5. 区块链返回智能合约地址+ABI(合约接口的二进制表示。合约接口用JS0N表示，包括变量、事件和可以调用的方法）。

  6. 前端通过Address+ABI+nonce，调用智能合约。

  7. 智能合约开始处理。

智能合约技术的产生对互联网变革非常重要，但是不能直接用于支撑DApp应用生态环境。侧链、VM也撑不起应用生态，因为我们知道应用运行于0S之上，而不是直接运行在裸机之上。一定程度上讲，VM、侧链可以类比图灵等价的裸机。

互联网是如何运作的

互联网所有的传输都通过RCP/IP协议族来传输，TCP/IP是面向连接的可靠字节流服务协议

TCP/IP协议族

有四层

  • 应用层：提供特定于应用程序的协议 HTTP FTP IMAP(邮件)
  • 网络控制层 发送数据包到计算机上使用特定的端口号的应用程序
  • 网络层 使用IP地址将数据包发送到特定的计算
  • 链路层 将二进制数据包与网络信号相互之间转换

TCP的可靠

tcp在建立连接会进行三次握手，每个收到的数据包都会向发送方发送ack确认，已确保发送成功

IP的传输

IP是不可靠的无连接协议，它并不关心数据包是否到达目的地，也不关系连接和端口号，目的是连接到目标IP

TCP传输的质量和顺序

当数据包过大，在网络层会进行分包，分包后传输的链路不一样，到达的时间不一样，TCP会根据数据包上携带序列号来进行排序重组，如果发送方在一个特定时间内（也就是重试时间）没有接受到接收方的ack确认，会再次重新发送

IP和IP地址的区别

Ip是一种协议 有两种标准 IPv4 2^32次方和IPv6 2^128

IP地址是一串数字192.0.0.1

网络传输

  1. 个人电脑
  2. 猫
  3. local ISP 互联网服务提供商
  4. regional ISP 经过多个主干网络
  5. NSP 网络服务提供商 大型网络 卖带宽给ISP
  6. NAP 每个NSP连接到至少三个网络访问点
  7. ISP NSP 所有网络提供都携带路由器，每个路由有当前子网络ip的路由表，当底层向上层发送数据时候，找不到会依次向上找，可能由一个主干网络跳到另外一个主干网络。

DNS服务

存在意义是IP别名，不让公司丢客户，也容易记，DNS是一个分布式数据库，存储了域名和IP的对应关系

JWT

什么是 JWT

  • JSON Web Token（简称 JWT）是目前最流行的跨域认证解决方案。
  • 是一种认证授权机制。
  • JWT 是为了在网络应用环境间传递声明而执行的一种基于
  • JSON 的开放标准（RFC 7519）。JWT 的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源。比如用在用户登录上。
  • 可以使用 HMAC 算法或者是 RSA 的公/私秘钥对 JWT 进行签名。因为数字签名的存在，这些传递的信息是可信的。

JWT 的原理

jwt流程

  • JWT 认证流程：
  • 用户输入用户名/密码登录，服务端认证成功后，会返回给客户端一个 JWT
  • 客户端将 token 保存到本地（通常使用 localstorage，也可以使用 cookie）
  • 当用户希望访问一个受保护的路由或者资源的时候，需要请求头的 Authorization 字段中使用Bearer 模式添加 JWT，其内容看起来是下面这样
    1
    authorization：bearer：<token>
  • 服务端的保护路由将会检查请求头 Authorization 中的 JWT 信息，如果合法，则允许用户的行为
  • 因为 JWT 是自包含的（内部包含了一些会话信息），因此减少了需要查询数据库的需要
  • 因为 JWT 并不使用 Cookie 的，所以你可以使用任何域名提供你的 API 服务而不需要担心跨域资源共享问题（CORS）
  • 因为用户的状态不再存储在服务端的内存中，所以这是一种无状态的认证机制

JWT 的使用方式

客户端收到服务器返回的 JWT，可以储存在 Cookie 里面，也可以储存在 localStorage。

  • 方式一
    • 当用户希望访问一个受保护的路由或者资源的时候，可以把它放在 Cookie 里面自动发送，但是这样不能跨域，所以更好的做法是放在 HTTP 请求头信息的 Authorization 字段里，使用 Bearer 模式添加 JWT。
    • GET /calendar/v1/events
    • Host: http://api.example.com
    • Authorization: Bearer
    • 用户的状态不会存储在服务端的内存中，这是一种 无状态的认证机制
    • 服务端的保护路由将会检查请求头 Authorization 中的 JWT 信息，如果合法，则允许用户的行为。
    • 由于 JWT 是自包含的，因此减少了需要查询数据库的需要
    • JWT 的这些特性使得我们可以完全依赖其无状态的特性提供数据 API 服务，甚至是创建一个下载流服务。
    • 因为 JWT 并不使用 Cookie ，所以你可以使用任何域名提供你的 API 服务而不需要担心跨域资源共享问题（CORS）
  • 方式二
    跨域的时候，可以把 JWT 放在 POST 请求的数据体里。
  • 方式三
    通过 URL 传输
    1
    http://www.example.com/user?token=xxx

常见的前后端鉴权方式

  • Session-Cookie
  • Token 验证（包括 JWT，SSO）
  • OAuth2.0（开放授权）

只要关闭浏览器 ，session 真的就消失了吗

不对。对 session 来说，除非程序通知服务器删除一个 session，否则服务器会一直保留，程序一般都是在用户做 log off 的时候发个指令去删除 session。然而浏览器从来不会主动在关闭之前通知服务器它将要关闭，因此服务器根本不会有机会知道浏览器已经关闭，之所以会有这种错觉，是大部分 session 机制都使用会话 cookie 来保存 session id，而关闭浏览器后这个 session id 就消失了，再次连接服务器时也就无法找到原来的 session。如果服务器设置的 cookie 被保存在硬盘上，或者使用某种手段改写浏览器发出的 HTTP 请求头，把原来的 session id 发送给服务器，则再次打开浏览器仍然能够打开原来的 session。恰恰是由于关闭浏览器不会导致 session 被删除，迫使服务器为 session 设置了一个失效时间，当距离客户端上一次使用 session 的时间超过这个失效时间时，服务器就认为客户端已经停止了活动，才会把 session 删除以节省存储空间。