CITAHub技术团队

大勇：

今天要分享的是：云平台中的HPA（horizontal pod autoscalers）水平自动伸缩。

大勇：

虽然通常我们可以部署Deployment时设置pod 的数量。 但是这样设置不够灵活，在不同的运行环境，会导致资源的浪费，而随着吞吐量的上升，又需要不同的设置。

大勇：

HPA 即通过检测pod CPU的负载，解决deployment里某pod负载太重，动态伸缩pod的数量来负载均衡。

大勇：

大勇：

HPA可以检测pod cpu的使用情况，通知deployment增加或者减少所管理pod副本的数量。

大勇：

1、假如已经部署好了一个工作负载，deployment/kms. 现在需要配置HPA。设置kms的pod数量最小为2，最大为10 执行命令：kubectl autoscale deployment kms --min=2 --max=10

大勇：

当我们手动强行设置pod数为1时，kms的pod数量会马上删除一个，然后又重新创建一个新的pod，始终维持到最小数量2

大勇：

从步骤1来看，只是 为POD 限定了一个可设置的范围，也没多神奇的地方。

大勇：

步骤2 将进一步根据POD 负载指标，来设置自动扩容策略

大勇：

假如POD 的CUP 利用率超过80% 自动扩容

大勇：

则这样设置kms 的HPA kubectl autoscale deployment kms --min=2 --max=10 --cpu-percent=80

大勇：

这里设置了cpu-percent=80，表示pod的cpu利用率超过了百分之80会自动扩容，最小规格2个pod，每超过80%，再自动扩容，直到 pod最大数10.

大勇：

自动扩容，也不是无限扩容，也会参考当前集群总体资源来设置一个合理的区间阈值

大勇：

HPA 虽然能通过各自策略，实现POD的配置自动伸缩； 主要是仰仗SVC的强大的负载均衡

大勇：

k8s中svc有三种类型，分别为ClusterIP、NodePort、LoadBalancer；但是当SVC的类型是ClusterIP时，明显的POD端启动多个或者减少时，对服务的持续访问影响最小；而Deployment的部署方式，通常用在无状态部署，相当于访问每个POD 提供的功能效果是一样的。 即Deployment 部署的应用，最适合HPA自动扩容的方式。

大勇：

而当：SVC 是NodePort 对集群节点端口有依赖；SVC 是LoadBalancer 时对IP资源有要求; 或者通过SatefulSet(有状态) 方式部署的应用，每个POD 都有编号，pod的主机名会映射到DNS，相当于每个POD的都是不一样的。 则这些场景的云应用，采用HPA 自动扩容的方式又不太适用。

大勇：

好了，我今天的分享就到这了，主要是对POD 的自动化扩容提供了一种方法HPA，以及对它使用的场景进行了简单分析。 就我们当前的部署来看，大部分都是deployment 方式，还是能使用上的。

洁洁：

我来分享个简单点的

洁洁：

就是did

洁洁：

分布式数字身份的英文缩写

洁洁：

拥有分布式身份不止是人，包括组织，甚至未来也包括物品。这些人或者组织、物品不简单依靠于原先中心化权威机构，无法被拿走或者删除，而且是终身携带的身份。

洁洁：

国际电子技术委员会将“身份”定义为“一组与实体关联的属性”。数字身份通常由身份标识符及与之关联的属性声明来表示，分布式数字身份包括：分布式数字身份标识符和数字身份凭证（声明集合）两部分。

洁洁：

分布式数字身份标识符（DID）是由字符串组成的标识符，用来代表一个数字身份，不需要中央注册机构就可以实现全球唯一性。通常，一个实体可以拥有多个身份，每个身份被分配唯一的DID值，以及与之关联的非对称密钥。不同的身份之间没有关联信息，从而有效地避免了所有者身份信息的归集。

洁洁：

所以每个人都可以拥有多个did

洁洁：

比如这样，不同身份不同did

洁洁：

“声明（claims）”是指与身份关联的属性信息，这个术语起源于基于声明的数字身份，一种断言（assert）数字身份的方式，独立于任何需要依赖它的特定系统。声明信息通常包括：诸如姓名，电子邮件地址、年龄、职业等。

声明可以是一个身份所有者（如个人或组织）自己发出的，也可以是由其他声明发行人发出的，当声明由发行人签出时被称为可验证声明。用户将声明提交给相关的应用，应用程序对其进行检查，应用服务商可以像信任发行人般信任其签署的可验证声明。多项声明的集合称为凭证（credentials）。

洁洁：

这种身份和传统的帐号有啥区别？

洁洁：

这种身份最大的好处是可以证明某个东西是我发的

洁洁：

传统身份可以被盗用，可以根据系统漏洞被仿冒…甚至dba直接往数据库插句话，你都没法否认

洁洁：

did只要守住自己的私钥，没有对内容签名。全网都可以轻松验假

洁洁：

did是怎么做到的呢？

洁洁：

其实很简单。 did生成的时候会生成一个document们的放在区块链上。这个document当中,就有这个身份的公钥。

洁洁：

所以每次发言的时候，把发言内容用私钥签个名一起发出去。

洁洁：

别人就可以轻松认定，这句话是你发出的。

洁洁：

其他人没有私钥是没办法轻松完成这个签名动作。哪怕是dba他也做不到。

洁洁：

所以在区块链的网络当中，私钥是不比当初常规系统中密码更加重要的东西。

洁洁：

现在基于这种特性，最成熟的应用是可验证声明，简称vc

洁洁：

可验证声明(Verifiable Credential)提供了一种规范来描述实体所具有的某些属性，实现基于证据的信任。DID持有者，可以通过可验证声明，向其他实体(个人、组织、具体事物等)证明自己的某些属性是可信的。同时，结合数字签名和零知识证明等密码学技术，可以使得声明更加安全可信，并进一步保障用户隐私不被侵犯。

洁洁：

这是一张大致示意图

洁洁：

像现在的绿码应用，其实是很容易钻空子

洁洁：

用上vc就可以轻松解决这些问题

洁洁：

目前w3c对这种身份做了定义

洁洁：

分散标识符(DID)是一种新型的标识符，它是全局惟一的、可解析的、高可用性的，并且可以通过密码验证。DID通常与加密材料(如公钥和服务端点)相关联，用于建立安全的通信通道。DID对于任何有利于自我管理、加密可验证标识符(如个人标识符、组织标识符和物联网场景中的标识符)的应用程序都非常有用。例如，目前W3C可验证凭据的商业部署大量使用分散的标识符来标识人员、组织和事物，并实现许多安全和隐私保护保证。

洁洁：

最后给大家看看did标识的结构是什么样的

Rain：

关于跨链，V神在2016发布过一篇报告《Chain Interoperability》，里面总结了3种跨链方案的实践：

• Notaries（公证员）
• Relays（中继技术）
• Hash-locking（哈希锁定）

Rain：

今天我就分享一下 Hash-locking（哈希锁定）的原理

Rain：

哈希锁定技术的核心原理是使用带有哈希锁定机制的合约进行资产锁定实现质押效果，为不同资产之间的交易提供了信任基础。

Rain：

使用哈希锁定机制的合约称为哈希时间锁合约（Hash Time Locked Contract，简称HTLC)

Rain：

HTLC 的核心是时间锁和哈希锁

Rain：

时间锁是指，交易双方约定在某个时间内提交才有效，超时则提案方案失效（无论是提出方或接受方）

Rain：

如果交易因为各种原因未能成功，时间锁能够让交易参与各方拿回自己资金，避免因欺诈或交易失败造成的损失

Rain：

哈希锁是指，对一个哈希值 h，如果提供原像 s 使得 hash(s) = h，则提案有效，否则失效

Rain：

HTLC 主要由两部分逻辑组成：哈希验证和过期验证

Rain：

前面是概念定义，接下来以2个持有不同区块链资产的用户使用HTLC进行资产交换来示例说明

Rain：

假设 A用户 和 B用户 有资产交换的需求，A用户 想用 m 个 x链数字资产 和 B用户 换 n 个 y链数字资产

Rain：

大家可以把 x链数字资产 替换为 BTC，把 y链数字资产 替换为 ETH 来做实例理解

Rain：

首先需要在两条链上部署哈希时间锁定合约，然后执行如下步骤进行跨链资产交换

Rain：

1. A用户 随机构建一个字符串 s，并计算出其哈希 h = hash(s)；

Rain：

2. A用户 将 h 发送给 B用户 的HTLC合约；

Rain：

3. A用户 锁定自己的 m 个 x链数字资产，并设置一个较长的锁定时间 t1, 并设置了获取该 x链数字资产 的一个条件：如果 B用户 能够提供 h 的原始值 s 就可以得到该 x链数字资产；

Rain：

4. B用户 观察到 A用户 HTLC合约中锁定了一个 x链数字资产, 然后 B用户 锁定自己的 n 个 y链数字资产 资产，并设置一个相对较短的锁定时间 t2, t2 < t1, B用户 也设置了获取条件：如果 A用户 能提供 h 的原始值 s 就可以获取 n 个 y链数字资产；

Rain：

5. A用户 将自己最初生成的字符串 s 发送到 B用户 的HTLC合约里取得了 n 个 y链数字资产；如果到时间点 t2 后仍未解锁，则退回 n 个 y链数字资产给 B用户；

Rain：

6. B用户 观察到步骤 5 中 A用户 的 s 值，将其发送给 A用户 的HTLC合约成功获取 m 个 x链数字资产；如果到时间点 t1 后仍未解锁，则退回 m 个 x链数字资产给 A用户；

Rain：

经过以上步骤，就完成了 A用户 用 m 个 x链数字资产 和 B用户 交换 n 个 y链数字资产

Rain：

以上的跨链事务流程图如下

Rain：

我们可以代入参数来理解：

A用户 = Alice
B用户 = Bob
x链数字资产 = BTC
y链数字资产 = ETH
m = 1
n = 20

Rain：

场景是：Alice 用 1 个 BTC 和 Bob 交换 20 个 ETH

Rain：

那事务流程图就是

Rain：

HTLC 的应用有以下的限制

Rain：

1. 协议兼容性较低

Rain：

HTLC 实施需要满足一些必要条件：

Rain：

一是用户资产所在区块链需要基于相同哈希算法（比如都使用比较常用的 SHA-256 哈希算法）；

Rain：

二是区块链需要兼容 HTLC 和其他可编程功能（如BTC的Bitcoin Script或ETH的智能合约）；

Rain：

三是交易双方需要在同一区块链上有交易账户；

Rain：

四是对于不包含资产托管账户（例如 Fabric）的区块链需要借助智能合约来构建账户概念。

Rain：

限制2. 时间锁机制造成退款时间过长

Rain：

时间锁有效降低了交易对手风险，但如果有中间节点因故无法进行交易，则必须等时间锁设定时间结束才能退款

Rain：

哈希锁定技术不是一种普适的跨链通讯机制，它解决的是价值交换问题，而不是信息传递问题，因此应用领域比较狭小

Rain：

以上就是我今天的分享

Rain：

抛出个问题：哈希锁定技术能否用于做跨链资产转移？

U2：

htlc应该是支持资产的原子交换

U2：

像侧链或者中继链这种relay模式的支持转移

U2：

相当于从a到b

U2：

另外研究区块链会发现，和传统的分布式事务算法里不同的是，区块链例一般都是用密码学加博弈论来保证的

U2：

像htlc本质上是一种序贯博弈

U2：

另外htlc也是依赖链本身的安全性，比如如果发生51%攻击依然会有资产丢失的风险

U2：

我记得某人写过一篇文章分析这个htlc博弈的过程，应该有一份是有一点点便宜可以占的，另外一方相对处于一个博弈的被动选择。比如就是说其中一方可以根据汇率选择是否进行交易，后后手只能根据前面的人选择被动选择，否则就有损失。

引言

量子通信是什么意思？ 到底有什么厉害之处？

量子计算机又是什么？为什么量子计算机是破解密码的终极武器？

几个月前，因为一次偶然的机会我接触了一本量子力学、量子通信的入门书籍，写得非常通俗易懂、幽默风趣。今天给大家分享的内容就来自这本书啦。

一、光的波粒二象性

说到主题之前，先谈一谈光的波粒二象性。

光是一种波还是一种粒子？一派是以惠更斯、麦克斯韦、赫兹等为代表的波派，一派是以爱因斯坦为代表的”粒子派“ ，两派斗争了非常久。光是一种波，这个非常好理解，因为光的干涉、衍射等现象很常见，大家都容易理解光是一种类似水波、电磁波一样的波。那么，爱因斯坦为啥会认为光是一种“粒子”呢？这得多亏“光电效应”这个实验，让爱因斯坦想到了答案。 （这个推理简单易懂，不展开说明，可以看书或百度）

那么到底哪一派获胜了呢？为了揭开谜团，科学家们做了很多实验（ N个版本的双缝干涉实验） ，想看看光到底是波还是粒子。

实验有N个版本，大家在物理课上学到的版本是最简单的版本，因为光具有波特性，经过2条缝之后，由于波的干涉，在最后的显示板上形成了”斑马线“样的干涉条纹。

科学家们再对实验进行升级，实验中的光变成一个一个光子打出。假设光是一种粒子，那么1个光子只能从一条缝穿过， 这样最终出现的就应该是2条杠，而不是斑马线状的干涉条纹。那么实际结果如何呢？

实验结果是：有时是斑马线，有时候是2道杠。这个结果，和你的“观察姿势”有关。假如你的实验装置能精确获取光子的路径信息，那么最终是2条杠。否则，实验结果就是斑马线。很反直觉对吗？像我们这种从小只学经典物理的普通人（甚至是爱因斯坦大神）觉得很难想象对吗？

所以量子力学的世界里，我们的思维方式就得改一改了。下面先给出波尔（堪称量子力学代言人）总结的量子世界3大基本原则：

• 1）态叠加原理
• 2）测不准原理：叠加态不可能精确测量 （粒子的位置与动量不可同时被确定，位置的不确定性越小，则动量的不确定性越大，反之亦然。）
• 3）观察者原理（只要光子的路径信息”可以被精确测量“的环境下，它就会自动坍缩，不能同时穿过2条缝了）

讲了这么多还没有讲到量子通信，不过很快就要讲到了！

二、量子纠缠和量子通信

上面主要说的是一个一个的量子，下面要隆重出场的是一对量子（或者叫孪生粒子 ，或者叫纠缠态的一对量子），量子纠缠才是加密通信的终极武器。

这里说的”一对量子“ 是怎么造出来的？ – 可以用粒子对撞机，两束粒子相撞，一个母粒子分裂成两个更小的粒子A和B。A和B动量大小相等，方向相反，A和B的角动量（类似自旋）也得相互抵消。如果说自旋态有上、下的定义区分（想象为顺时针、逆时针）。那么，根据量子理论，在不被观测的情况下，粒子处于多种可能性的叠加态。即：不是向上，也不是向下，而是两者并存！观测之后，两个粒子（A、B）之间才有上下之分，保持阴阳平衡，就算A和B相隔十万八千里，这种纠缠关系也会存在。这个就是量子纠缠。

这一对量子，就好比一对魔法硬币，不管千山万水，只要一枚硬币翻到正面朝上，另一枚一定会瞬间变成反面朝上。（超距作用）

这能为我们干点啥呢？如果把上面的量子A和B放在通信的两端。请看下面的3个步骤：

• 1）量子A （想象成硬币）抛出 反正正反，量子B 收到相反值，很容易就知道A发出的是反正正反—　这个就是对称密钥
• 2. A端的人用微信给B端的人补发一串同长度的纠错码 错对对错 — 这个就是密文
• 3）B端的人得到了有用的信息 正反反正 （可能翻译过来就是：明天偷袭珍珠港）— 这个就是明文

这个过程就是大名鼎鼎的量子通信了。

以前你可能以为量子通信一定超快，现在知道了，它不是快，微信传输的延时几秒，它就要延时几秒。它的威力在于加密！而且无条件安全的加密！

什么是绝对安全的加密，需要具备3大条件（香农证明过的）：

• 1）随机加密
• 2）明文密文等长
• 3）一次一密

这3个条件量子通信都满足了（不信你再看看）。

“无条件安全的加密”，听起来很牛是不是，别急，量子通信还有更牛的——它具有反窃听属性：

它能发现窃听者，而且，窃听者不知道被我发现了！

所以量子通信不怕窃听，也不怕破解，它只怕干扰。（比如，用强激光照射接收器）

好了，量子通信的就是这么简单又厉害。

再来看看我们熟知的加密方法：

• 1）传统的对称加密。它怕啥？怕密码本泄露！
• 2）非对称加密（如RSA）。 它怕啥？ 怕算力。它是能被破解的。（超级计算机曾经用几个月的时间破解过，如果是量子计算机呢？）

哦，刚才说到量子计算机。量子计算机为啥快？

量子计算机加速的根源在于量子叠加态的存在，在经典计算中，N位比特的CPU在同一时刻只能存储一种状态，但在量子计算中，N位量子比特的CPU在同一时刻可以同时保存2^N 个状态。所以，量子计算机的恐怖性能完全来源于并行，而非某种绝妙的算法。

我的分享就是这些。

如果想要了解更多，比如锲而不舍的科学家们是如何将双缝干涉实验改进演变到几近变态版本的，可以查阅原文：《猫、爱因斯坦和密码学 - 我也能看懂的量子通信》 作者：神们自己

U2：

今天分享下openzeppelin的Upgradeable Smart Contract，就是可升级智能合约

U2：

我们先看下如何用他这个提供的插件来写智能合约

U2：

然后再来介绍下里面的原理和实现逻辑

U2：

首先我看一个正常的合约

U2：

比如一个合约里有他的初始化构造方法，我们要把这个构造方法，替换成initialize方法

U2：

我们先不考虑为什么需要这么做，我们先看下他的使用，后面我们再去看他的原理

U2：

比如这个MYcontract合约，我们就把他的构造方法换成initialize

U2：

然后能因为构造方法其实只能被调用一次

U2：

为了防止出现被错误调用，所以这里加了一些条件限制

U2：

我记得很早以前某篇文章里介绍智能这种编程方式也叫，面向条件的编程。

U2：

大家感兴趣可以去查查这个面向条件编程，因为无论是普通合约逻辑的编写，还是在安全方面做的一些保护，比如防重入攻击，都有点这个条件编程的思想。

U2：

我们接着介绍

U2：

其实每次这样去写这个initialize的方法就很麻烦

U2：

所以这个openz就帮我们实现了一些逻辑，我们只要继承这个就好了

U2：

那咱们平时写合约的时候，实际上还有一些合约继承的东西

U2：

这种情况能，就要稍微处理下

U2：

然后如果咱们用了erc20这种合约咋办呢？

U2：

这个其实openz也提供了他标准的可升级的erc20的实现，我们把原来继承erc20，直接替换掉就好了

U2：

然后能还要注意一点，就是在变量声明的时候，不要做初始化，Avoiding Initial Values in Field Declarations

U2：

比如这个

U2：

这种其实就相当于，我们写了一个构造方法，然后在构造方法里初始化这个storage

U2：

就需要把他改成上面这样的

U2：

还有一种是常量

U2：

这种不一样的，他实际上是编码在合约ｃｏｄｅ里的

U2：

我们在部署合约的时候，evm实际上在完成构造方法后，构造方法这段代码实际上就没有保存在合约地址下的code的，因为反正只是在部署的时候用。

U2：

但是初始化的常量实际上会跟随这个合约code，保存在合约地址下的代码里。

U2：

然后这个初始化里构造的变量呢，也是以storage的形式存下来的。

U2：

然后能，在初始化合约的时候，可能在初始化方法中会创建一个新的合约实例

U2：

比如这种

U2：

这能里面的这个erc20合约实际上是不支持升级的

U2：

如果想要这个合约支持升级怎么处理呢？

U2：

实际就是先部署里面这个合约，然后在初始化的时候把这个里面的合约地址再传进去就好了

U2：

然后能，咱们在升级合约的时候也要注意几点

U2：

第一不要更改原有的storage

U2：

比如原来是这样

U2：

1
2
3
4

contract MyContract {
    uint256 private x;
    string private y;
}

U2：

我们不能把这个变量类型改掉

U2：

1
2
3
4

contract MyContract {
    string private x;
    string private y;
}

U2：

也不能换顺序

U2：

1
2
3
4

contract MyContract {
    string private y;
    uint256 private x;
}

U2：

也不能在前面插入一个变量

U2：

1
2
3
4
5

contract MyContract {
    bytes private a;
    uint256 private x;
    string private y;
}

U2：

能做的是，可以给这个变量换个名字，或者在后面追加一个变量

U2：

比如这个

U2：

1
2
3
4
5

contract MyContract {
    uint256 private x;
    string private y;
    bytes private z;
}

U2：

就是加在最后

U2：

当然还有其他的错误使用情况，大家可以看他们的官方文档

U2：

然后能这个原理是怎么实现的呢

U2：

其实很简单

U2：

他这个就是用了一个代理合约

U2：

1
2
3
4
5

User ---- tx ---> Proxy ----------> Implementation_v0
|
------------> Implementation_v1
|
------------> Implementation_v2

U2：

这个我们用户调用的一直都是这个代理合约

U2：

然后具体的实现合约可以换掉，然后把地址绑定到这个代理合约之类

U2：

我们看下这个代理合约的大致的逻辑思路

U2：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

assembly {
    let ptr := mload(0x40)

    // (1) copy incoming call data
    calldatacopy(ptr, 0, calldatasize)

    // (2) forward call to logic contract
    let result := delegatecall(gas, _impl, ptr, calldatasize, 0, 0)
    let size := returndatasize

    // (3) retrieve return data
    returndatacopy(ptr, 0, size)

    // (4) forward return data back to caller
    switch result
    case 0 { revert(ptr, size) }
    default { return(ptr, size) }
}

U2：

这个是assembly写的

U2：

这个第一步就是把calldata拷贝出来，就是交易里的data，第二步骤就是用这个delegatecall，然后第三就是获取return data，第四就是再吧这个returndata 返回

U2：

我们主要看这个delegatecall

U2：

solidity里有几种call，大家可以对比下这几个的区别

U2：

我们主要看这个delegatecall

U2：

这个能，其实就是把目标合约的code在当前合约的环境下执行，使用当前合约的storage

U2：

就是说逻辑合约的代码其实是被执行了，但是逻辑合约的storage其实是没有用的

U2：

他用的是在代理合约的storage

U2：

所以能，其实合约在初始化的时候，如果用solidity的构造方法，这个storage就留在逻辑合约里了，所以呢前面的把构造合约该成init就是这个道理，通过代理合约来调用iinit

U2：

然后这些storage就留在这个代理合约里了

U2：

然后后面就可以持续升级

U2：

刚才讲到在代理合约里保存逻辑合约的stroage

U2：

这里就有一个问题，就是原来代理合约因为也要保存逻辑合约的地址

U2：

比如在代理合约里声明了一个stroage

U2：

然后因为在solidity实现的时候，他会把这个storage给一个postion，然后实际上是按照他声明的位置来确定最终在合约下面的抽象模型里的kv里存的位置的

U2：

比如我们声明了三个变量

U2：

1
2
3

address a;
address b;
address c;

U2：

这三个实际上存在哪里是跟他的position有关的，就是变量的顺序

U2：

最终保存的时候我记得好像是按照合约地址＋position来作为这个storage的key的，然后再用mpt树做处理，具体这的细节，大家可以以后去研究。

U2：

然后这里可能就有一个问题

U2：

就是proxy这里的storage，比如第一个和逻辑合约里的第一个storage，因为都是第一个，都存到proxy合约里

U2：

所以这里就冲突了

U2：

怎么办呢？

U2：

我们给他一个随即的slot就可以了

U2：

这里可以参考https://eips.ethereum.org/EIPS/eip-1967

U2：

原理很简单，实际就是算一个随机的数，然后用solidity的assembly语言里的一个设置stroage的命令，设置这个值就好了

U2：

这样就解决了代理合约和实现合约里的stroage冲突的问题

U2：

然后在实现合约里，因为stroage实际无论怎么升级都是公用的代理合约里的

U2：

所以这里就不能修改原来的stroage，要不然就冲突了

U2：

然后在使用上，openz和truffle也好，还有和一些其他的合约开发工具都是做了集成，使用起来都还是比较方便的

U2：

我的介绍就到这里

U2：

谢谢大家

王快乐：

好！我来分享一下 高可用的网络架构 吧

王快乐：

这个高可用的网络架构更偏向于基础设施，与我最近的工作内容相关。

王快乐：

希望能给应用层网络高可用带来启发吧。

王快乐：

所谓基础设施的高可用网络架构，是为了解决提升带宽、增加可靠性，先给大家分享一下基础设施高可用网络架构的拓扑图。

王快乐：

这个架构，一会儿再解释。我先分享一些简单网络的知识，做个铺垫。

王快乐：

华为有个 eNSP 模拟器，它提供一些网络设备，可以让我们随意组合，来进行网络实验。

这个是我昨晚做实验的一个拓扑，用来测试 ACL 了。提升网络安全的。通过 ACL 来控制，哪些部门 的 哪些设备 能访问 哪些网络。

这是 eNSP 模拟器，挺有意思的。我总不能买一堆设备回来做实验。除了华为，华三和思科也提供自己的模拟器，意图都是相同的。

王快乐：

我们常见的网络设备，一般有交换机、路由器、防火墙、无线设备（AP、AC），还有 WAF 这些设备就比较少见。

基础设施的高可用网络架构里面，常规配置是：交换机 比较多，相当多；路由器一般就两台；防火墙也两台；其他设备一边根据需求、成本各方面进行综合考虑是否采用

主要的还是交换机。

王快乐：

交换机一般分为两类，盒式交换机，框式交换机。

盒式交换机就是我们平时见到的那种，一个方形的盒子。

框式交换机式数据中心用的，挺大的，各部分都是模块化的。

王快乐：

这个是盒式交换机

王快乐：

这个是框式交换机，各个部分都是模块化的，坏了直接换。

说到这，有句话真的是，技术进步的厉害，思想进步的慢。与盒式交换机比，框式还是模块化思想，将各个部分模块化、易插拔，坏了直接换模块。

王快乐：

盒式交换机，小型园区网、企业网会使用。框式交换机，一般数据中心会使用。

王快乐：

路由器、防火墙、无线设备（AP、AC），这些就不介绍了，这些不是这次分享的重点。

王快乐：

然后，我们再看一下交换机角色。这里有用到了分层的思想。

交换机的角色，分为三类：接入层、汇聚层、核心层。

从拓扑图里看，最下面是接入层，最上面是核心层。

接入层交换机：就是我们平台连接 PC 的交换机，功能很简单。听名字也是，只能接入设备，没有其他功能了。

汇聚层交换机：就是将链路进行汇聚，负责网络层的二层数据转发，只涉及 MAC 地址。也就是同个网络数据的转发。可以直接理解成内网数据转发。

核心层交换机：就有点路由功能了，三层转发，会涉及一些 IP 网络。交换机也有路由功能的，只是做的比较简单。说是分层思想，但也不可能 100% 都分开，也很小的耦合和关联度。

yzl：

ip网络是ip协议层的网络吗

王快乐：

我们再来看一下交换机和交换机、交换机和终端设备的连接方式。

交换机和终端设备：我们平时连的比较简单，直接 PC 连上就行了。服务器不是这个样子，公司内网的服务器有四个网口，需要连接两台交换机，提供冗余和带宽的。

交换机和交换机：那绝对是个“环路连接法”。从图上也能看出来，一台交换机，连了两台设备，两台设备又互联，就是个环路。

抽出来就是下图的一个简单拓扑。模拟器比较简单，Server 没有那么多网口。

王快乐：

环路的问题不用担心，有生成树协议，STP RSTP MSTP。

通过这些协议，交换机进行角色选举，切换端口状态。端口状态有的：AP DP BP RP EP 五种状态，这个无需深究。

端口角色确认之后，某些端口是阻塞的，无法转发数据，这样就自己破除环路了。

自动将环路剪裁成树形结构，所以叫生成树协议。

王快乐：

有人可能会问……其实没人问……为啥非要接个环路，再引入一个协议，不接成环路不就好了？

为了冗余，假如一条链路断了，我们还可以走另外一条。

Shawn：

条条大路通罗马

王快乐：

是的，就是这个样子。除了冗余外，还能增加内网带宽。

王快乐：

现在回到最开始的架构图

iStack，Intelligent Stack 是华为的叫法，思科也有类似的技术。虚拟交换机，将两个交换机合并成一个逻辑的交换机，在逻辑上是一台设备。iStack 是用盒式交换机的。

CSS CLuster Switch System，也是华为的叫法，也是将多台设备逻辑成一台设备。CSS 需要使用框式交换机实现。

Eth-Trunk：是链路聚合。两台交换机之间，连了很多线。但是，这些线是逻辑上的一根线，提成带宽，增加冗余。

STP：是生成树协议，防止线连多了以后，出现环路。

整个网络，通过设备的方式（双设备，成本高），并辅以软件实现（Eth-Trunk，成本低）来提高冗余、增强可靠性。

王快乐：

网络是个基础设施，里面涉及了很多东西，但是这个不是这个分享想表达的。今天的分享想表达的是 技术千变万化，但是背后的思想是固定，我们可以把这些思想借用过来，并进行进一步的提升这些思想，而不仅局限于技术的提升。

王快乐：

好了，今天就分享这么多吧，谢谢大家聆听。[呲牙]

洁洁：

@王快乐 讲讲家用路由和企业路由的区别。

志伟：

最主要的区别就是贵[破涕为笑]

Rain：

实现可靠性的级别不同，企业级要求7x24工作强度不能异常，家用的可接受每日重启

王快乐：

绝大多数东西都是需求和业务驱动的，然后技术只是做个实现。

所以，两者的差别就是功能多少的差别。

家用路由器的需求就是上网就行了：
1）PPPoE 做个拨号，NAT 做个地址转换；
2）DHCP 自动分配地址，解决用户不会配置、配置麻烦的问题。
3）再就是无线功能
4）前三点足够了，其他的功能都是面向其他有特殊需求的用户的。
5）然后功能多了，再提高一下性能。

家用路由器以解决家庭上网需求为主。

企业路由器就不一样，那老复杂了：
1）首先就没有无线功能，路由器的核心是路由三层数据包。家用路由器里并不强调这点。
2）焦点还是企业需求：7x24、可用性、QoS、网络隔离、访问安全、外部接入。

U2：

我分享一篇文章吧

U2：

打浦路（Taproot）比你想的宽｜预言家周报#143

U2：

这个是介绍最新的比特币的一个软分叉taproot

U2：

这里主要的几个特性，一个是默克尔化抽象语法树（Merklized Abstract Syntax Trees, MAST），这个其实我理解还是默克尔树的一种用法

U2：

比特币为什么搞这个呢？

U2：

其实还是跟原来的P2SH的设计有关

U2：

我们看下原来比特币P2SH的设计

U2：

U2：

这里其实在一开始未解锁交易的时候，这笔资金有一定的隐私性，但是一旦解锁，就必须暴露全部的脚本，隐私性不好

U2：

所以现在其实是将一个合约不同的条件分支组成一个默克尔树

U2：

U2：

这里我也在思考联盟链或者eth是否也能实现类型的效果呢？

U2：

这个问题大家可以思考下

U2：

另外就是Schnorr 签名，这个签名一个比较重要的属性就是可以把多个私钥的签名，可以聚合成一个签名，看起来仿佛是一把私钥签出的。

这样的话就为n-n 这种签名提供一种隐私性

U2：

对于其他人来看，其实并不知道是一个人签的还是多个人签的

U2：

对于m-n的签名呢？和前面的的Mast结合，其实也能打到一样的效果。比如一个2-3的多签名，可以理解为多个不同分支的2-2

U2：

Gregory Maxwell 写道 ：

在讨论默克尔化脚本时，一个大家常常提起的问题是，我们能否实现一种精巧的合约，使其与最常见、最无聊的支付没有分别。不然的话，使用这些时髦技术的输出的匿名集，也就是另一个小众集合而已，在实践中没有多大的意义。

U2：

Maxwell其实提到了一种抽象而且通用的做法

U2：

就是如何做到隐私，而这个隐私又是一种普通的交易

U2：

原来其实个人钱包和合约钱包是有差别的

U2：

但是可以通过MAST和Schnorr签名，再把个人和合约用户都统一到一个脚本模式下

U2：

P2TR

U2：

然后经过这样的处理，其实对于外界来看，是无法分辨到底是个人，还是合约，做到大隐隐于市

U2：

其实历史上的每一次比特币的升级都是非常慎重，修改也是非常小的，但是也是非常精密的

U2：

最后留给大家一个问题，如何在eth合约上实现类似的特性呢？

————— 2021-11-06 —————
rink：

感觉以太坊上不好做，因为以太坊智能合约是任意的计算程序，而比特币的lock script是一个判定程序，只返回成功与否。我在秘猿的时候其实研究过这个问题。我当时就想用正常的程序描述业务操作，然后有个工具能自动提取出其中的判定程序。当然有个最简单的方法，就是assert，但是这还是需要在链上重复所有的计算。我设想的是像零知识证明一样，验证和计算是不对等的，验证的工作量要比计算少。这个好像是没有找到通用的解决方案。