麻省理工学院对来自全球近 20,000 名专业人士进行了调查 - 50% 来自北美，21% 来自欧洲，19% 来自亚洲，其余来自澳大利亚、南美和非洲。要点包括 ...

1. 按重要性排序任务，并以明确的目标行动。​

• 在写任何长度的内容之前，准备一个逻辑顺序的提纲，以帮助你保持正轨。
• 在前一天晚上修订你的日历，以强调你的优先事项。在你的日程安排旁边写下你的目标。
• 在任何会议之前向所有参与者发送详细的议程。
• 开始大型项目时，尽早勾勒出初步结论。
• 在阅读任何冗长的材料之前，确定你具体的目的。

2. 处理信息和任务过载。​

• 通过查看主题和发件人跳过大多数消息。
• 将日常过程（如穿衣或吃早餐）变成例行公事，这样你就不必花时间思考它们。
• 每小时检查一次设备屏幕，而不是每几分钟检查一次。
• 将大型项目分成几个部分，并在完成每个部分时奖励自己。
• 在可行的情况下，委派那些不干扰你主要优先事项的任务。
• 在你的日常日程中留出时间来处理紧急情况和意外事件。

3. 你的同事需要简短的会议、及时的沟通和明确的方向。​

• 立即回复来自重要人士的消息。
• 为了吸引观众的注意力，尽量从一些笔记中发言，而不是阅读准备好的文本。
• 将任何会议限制在 90 分钟或更少，但最好更少。在每个会议结束时，划定下一步的措施和责任。
• 为了提高团队的表现，建立程序以防止未来的错误，而不是进行指责游戏。
• 为任何团队工作设定明确的目标和成功指标。

MIT 调研了来自全世界的近两万专业人士，他们 50% 来自北美，21% 来自欧洲，19% 来自亚洲，剩下的来自澳大利亚、南美和非洲。最后归纳出了这些让人的生产率脱颖而出的方法。

1. 根据任务的重要性来规划你的工作，然后带着明确的目标行动。​

• 在前一天晚上修改你每天的日程表，强调你的优先事项。在日历上的每个日程旁边，写下你的目标。
• 在任何会议之前，将详细的议程发给所有与会者。
• 当着手进行大型项目时，尽快勾画出初步结论。
• 在阅读任何长篇材料之前，先确定你对它的具体目的。
• 在写任何长度的东西之前，编写一个有逻辑顺序的大纲，以帮助你按部就班。

2. 制定有效的技巧来管理超负荷的信息和任务。​

• 把每天的流程，比如穿衣服或吃早餐，变成例行公事，这样你就不会花时间去想这些事情。
• 在你的日常日程中留出时间来处理紧急事件和意外事件。
• 每小时检查一次设备的屏幕，而不是每隔几分钟检查一次。
• 通过查看主题和发件人，跳过大部分的信息。
• 将大型项目分成若干个部分，并在完成每个部分后奖励自己。
• 在可行的情况下，将那些不影响你首要任务的任务委托给他人。

3. 了解同事对简短会议、响应式沟通和明确方向的需求。​

• 将任何会议的时间限制在90分钟以内，但最好是更短。在每次会议结束时，划定下一步的步骤和这些步骤的责任。
• 对那些对你来说很重要的人的信息，要立即做出回应。
• 为了吸引听众的注意力，根据一些笔记发言，而不是读准备好的文本。
• 为任何团队的工作建立明确的目标和成功指标。
• 为了提高你的团队的表现，建立程序来防止未来的错误，而不是玩责备游戏。

需求​

在线评测系统主要是一个可以远程执行代码的地方，用于教育或招聘目的。在这个设计中，我们专注于设计一个用于面试准备的 OJ，类似于 Leetcode，具有以下需求：

• 它应该具有核心的 OJ 功能，如获取问题、提交解决方案、必要时编译和执行。
• 它应该具有高可用性，采用 异步 设计，因为运行代码可能需要时间。
• 它应该具备水平扩展性，简单易扩展。
• 它应该稳健且安全，以执行不受信任的源代码。

架构​

下面的架构以异步执行的队列和安全执行的沙箱为特色。每个组件都是可单独部署和扩展的。

组件​

表现层​

用户代理通常是一个像 coderoma.com 这样的网页或移动应用。它显示问题描述，并为用户提供一个代码编辑器来编写和提交代码。

当用户提交代码时，客户端将获得一个令牌，因为这是一个异步调用。然后客户端轮询服务器以获取提交状态。

API​

请参见 公共 API 选择 以了解我们可以选择的协议。让我们在这里设计接口本身，并以 GraphQL 为例：

type Query {
  problems(id: String): [Problem]
  languageSetup(id: String!, languageId: LanguageId!): LanguageSetup
  submission(token: String!) Submission
}

type Mutation {
  createSubmission(
    problemId: String!
    code: String!
    languageId: LanguageId!
  ): CreatedSubmission!
}

enum LanguageId {
  JAVA
  JS
  ELIXIR
  # ...
}


type Problem {
  id: String!
  title: String!
  description: String!
  supportedLanguages: [Float!]!
}

type LanguageSetup {
  languageId: LanguageId!
  template: String!
  solutions: [String!]!
}

type Status {
  id: Float!
  description: String!
}

type Submission {
  compileOutput: String
  memory: Float
  message: String
  status: Status
  stderr: String
  stdout: String
  time: String
  token: String
}

type CreatedSubmission {
  token: String!
}

API 层将提交记录在数据库中，将其发布到队列中，并返回一个令牌供客户端将来参考。

代码执行引擎​

代码执行引擎 (CEE) 轮询队列以获取代码，使用沙箱来编译和运行代码，并解析编译和执行的元数据。

沙箱可以是 LXC 容器、Docker、虚拟机等。我们可以选择 Docker，因为它易于部署。

Coderoma.com​

我最近在学习 Elixir 并创建一个在线评测系统 coderoma.com 以进行日常练习。它现在支持 Elixir 和 JavaScript。我正在添加更多语言（如 Java）和问题。

我们可能会举办未来的活动来提高您的编码技能。请加入我们，访问 https://t.me/coderoma 以获取英语社区，或使用您的微信扫描以下二维码 onetptp 并回复 刷题 以加入中文社区。

PWA 代表渐进式网页应用。早在 2014 年，W3C 发布了服务工作者的草案，随后在 2015 年，Chrome 在生产环境中支持了它。如果我们将服务工作者的出现视为 PWA 的核心技术之一，那么 PWA 的诞生年份就是 2015 年。在关注 PWA 是什么之前，让我们先了解一下我们为什么需要它。

1. 用户体验。回到 2015 年，前端开发者花费大量时间通过加快初始页面的渲染、使动画更流畅等方式来优化网页。然而，在用户体验方面，原生应用仍然占据优势。

2. 用户留存。原生应用可以固定在手机的主屏幕上，并通过通知将用户带回应用，而网页应用则无法做到这一点。

3. 利用设备 API。Android 和 iOS 提供了丰富的设备 API，原生应用可以轻松在用户许可下使用。然而，当时浏览器并未完全支持这些 API。

谷歌的教程 为什么构建渐进式网页应用 将这个问题总结为“广泛覆盖，低参与度”。

为了应对移动时代网页应用的劣势，PWA 应运而生。

当谷歌提出 PWA 时，并没有一个精确的定义。它不是一种特定的技术，而是一种组合技术，旨在改善用户体验。这些技术包括 Web 应用清单、服务工作者、网络推送等。

PWA 的主要特性如下：

• 可靠性 - 即使在不稳定或断开的网络环境中也能快速加载。
• 用户体验 - 响应迅速，具有流畅的过渡动画和用户操作反馈。
• 粘性 - 像原生应用一样，可以添加到主屏幕并接收离线通知。

PWA 本身在两个方面强调了 渐进性。

1. PWA 仍在不断发展；
2. PWA 向下兼容且不具侵入性。开发者使用新特性几乎没有成本 - 开发者可以逐步将其添加到现有网站中。

谷歌的 "渐进式网络应用检查表" 定义了 PWA 的最低要求。

• 通过 HTTPS 提供服务。
• 页面在桌面、平板和移动设备上应具有响应性。
• 所有 URL 在断开连接时应有内容显示，而不是默认的浏览器页面。
• 需要将 Web 应用清单添加到桌面。
• 页面加载更快，延迟更短，即使在 3G 网络上。
• 在所有主要浏览器中正确显示。
• 流畅的动画和即时反馈。
• 每个页面都有自己的 URL。

PWA 的特性​

PWA 结合了网络应用和原生应用的优点，给我们带来了以下特性。

• 渐进性 - 适用于所有浏览器，因为它是在考虑渐进增强的情况下开发的。
• 连接无关 - 能够利用服务工作者实现离线或低网络连接。
• 原生体验 - 基于应用外壳模型，应该具有原生应用的交互。
• 持续更新 - 始终保持最新，没有版本或更新问题。
• 安全性 - 通过 HTTPS 提供服务。
• 可索引 - 清单文件和服务工作者可以被搜索引擎识别和索引。
• 粘性 - 通过推送离线通知等，可以让用户回到您的应用中。
• 可安装 - 用户可以轻松将网络应用添加到主屏幕或桌面，而无需前往应用商店。
• 可链接 - 通过链接分享内容，无需下载和安装。

更具体地说，PWA 相较于原生应用的优势是什么？开放性和可索引性。用户几乎无法即时安装原生应用，也无法无缝搜索原生应用。

下表展示了传统网络应用、原生应用和 PWA 在各个特性上的比较。

Facebook 从最初的 PHP 服务端渲染网站发展至今已经 16 个年头，Web 开发的外部环境已经是沧海桑田，在老构架上开发新 Feature 的成本也越来越高。为了得到“App 的体验”以及卓越的性能， 他们用 React 和 Relay 重写了整个主网站，基于两个原则 —— “尽可能少尽可能早”、“提升开发体验以服务用户体验”。

将这两个原则应用到四个主要元素 （CSS，JavaScript，数据，导航） 上，得到如下经验

1. 改进 CSS
   1. Atomic CSS: 使用 Build 时生成的原子类 CSS 将首页的 CSS 减少 80% - 因为这种 CSS 的条目的数量接近 log N——样式的总量是随着独特的样式增长的，而不是跟着代码里面写的样式和 feature 的数量增长的。我们 Uber 就使用的 Styletron 来做这件事情。
   2. CSS-in-JavaScript: 用类似于 stylex.create({}) 这种方法来为组件生成 Style，跟组件放到一起，以增加可删除性，让样式更容易被维护。
   3. 统一使用 rem 让缩放的时候体验更好， Build 时自动将 px 转化成 rem.
   4. 使用 CSS 变量实现黑暗模式
   5. 使用 HTML 内嵌 SVG 作为图标，解决图标延迟渲染的一闪问题
2. 分拆 JavaScript 以优化性能
   1. 增量式加载代码，把 500 KB 的总代码，分成 50KB Tier 1，150KB Tier 2, 300KB Tier 3，分别对应骨架内容、首屏内容 、非 UI 内容，然后按需加载。
   2. 只在需要的时候加载实验代码
   3. 根据数据加载相应的代码，比如图片数据加载图片组件、视频数据加载视频组件
   4. 给 JavaScript 的大小做预算，严格监视代码尺寸的变化
3. 尽早载入数据
   1. 预加载：用 Relay 能够立马知道首屏所需要的数据，在下载代码的同时，也 stream 这些数据
   2. 用 stream 的方式减少 round trips
   3. 延迟加载现在不需要的数据
4. 定义路由 map 以加速导航
   1. 尽早获得路由的定义
   2. 尽早预先获取资源，在 hover 或者 focus 的时候就开始了，导航变化之后，如果还没有加载完，先用 React Suspense transitions 保留当前页面，只有加载完之后才真正切换。这样就能跟标准的浏览器体验保持一致。
   3. 并行下载代码和数据。通常是先下载代码再下载数据，这样是串行的；FB 让数据和代码在一个 round trip 里面同时下载。

以正确的方式饮食可以显著影响你的健康。听到来自不同来源的各种建议，你可能会很难判断哪一个最有帮助。书籍《如何不死》提供了八个由科学研究支持的实用建议，帮助你建立健康的饮食习惯。

采用植物性饮食​

植物性饮食已被证明对健康的积极影响远超美国社会中的其他食物。一项中美-康奈尔-牛津研究项目研究了 1980 年代中国人的饮食。研究发现，贵州省在 65 岁以下男性中冠心病的死亡率最低，而那里的人们消费的动物性食物最少。

此外，植物性饮食可以促进患者的康复。生活方式医学的先驱纳森·普里提金和迪恩·奥尔尼什将患有晚期心脏病的患者置于植物性饮食中，随后他们见证了症状显著改善。例如，患者动脉中的有害斑块溶解的速度比平常快。

多吃水果，尤其是浆果​

每天四份水果，其中包括一种浆果，是健康饮食的关键。每天多吃一份水果已被证明可以使慢性阻塞性肺病的可能性降低 24%。值得注意的是，浆果对肝功能、抗癌和免疫系统的积极影响尤为重要。在 2014 年的一项研究中，14 名患者在食用黑覆盆子九个月后，发现其息肉负荷显著下降。

蔬菜不可或缺​

蔬菜在预防疾病方面发挥着至关重要的作用。被称为“绿叶之王”的羽衣甘蓝可以降低人们的胆固醇水平。在 2008 年进行的一项为期三个月的研究中，高胆固醇患者每天被要求饮用三到四杯羽衣甘蓝汁。益胆固醇的比例显著增加，相当于跑步 300 英里的效果。此外，十字花科蔬菜有助于增强肝脏和肺部功能。

因此，建议每天五份蔬菜中有两份应为绿叶蔬菜（例如羽衣甘蓝、芝麻菜和瑞士甜菜）。另外两份可以是胡萝卜、甜菜或蘑菇。最后一份应为十字花科蔬菜，如西兰花、卷心菜或花椰菜。

每餐推荐豆类和全谷物​

美国癌症研究所建议每餐应包含豆类或豆科植物，因为它们含有无动物成分的蛋白质和纤维。海军豆和斑豆也是降低不良胆固醇的良好替代品，适合不喜欢大豆的人。它们还可以减缓糖的吸收并放松胃部。与豆类类似，人们每天应摄入三次全谷物。2015 年的研究发现，饮食中包含全谷物的人寿命更长。

多吃坚果和种子以获得更好的营养​

在 1990 年至 2010 年间进行的全球疾病负担研究发现，摄入过少的种子和坚果是全球死亡和残疾的第三大饮食原因。即使是一份巴西坚果也相当于降胆固醇药物的效果。坚果和种子有助于排毒多余的铁。它们还可以增强骨密度。在所有种子中，推荐奇亚籽、麻籽、南瓜籽、芝麻和葵花籽。它们是日常餐点中调味酱和沙拉酱的绝佳替代品。

在食物中加入香草和香料​

香草和香料不仅可以为菜肴增添风味，而且在预防疾病（尤其是癌症）方面也至关重要。在所有食物中，它们的抗氧化剂含量最高。在 2010 年进行的一项研究中，服用藏红花的阿尔茨海默病参与者的认知功能结果优于服用安慰剂的参与者。此外，丁香和肉桂等香料可以因其抑制的酶而减轻抑郁。

值得一提的是，姜黄被证明是所有香草和香料中预防癌症效果最好的。由于姜黄迅速消失，与黑胡椒一起食用可以减缓这一过程并帮助吸收。咖喱粉是一个不错的选择，因为它通常含有胡椒和姜黄。然而，姜黄并不适合所有人。患有胆结石和肾结石的人应限制其摄入。

让水成为首选饮品​

理论上，人类每天应饮用五杯 12 盎司的饮料，而纯水始终是最佳选择。许多文章声称每天喝八杯水是必须的，但几乎没有科学证据支持这一点。我们的每日水分摄入不仅来自饮料，还来自水果和蔬菜。

除了水，咖啡和茶也可以是不错的替代品，因为它们在某种程度上都有益于健康。例如，塔夫茨大学进行的研究显示，茶在降低血压方面发挥了显著作用。

普通人在生活和工作中做决策机会并不多，也很难有机会练习和提高自己的决策水平。大多数人的决策靠直觉，而理性的决策靠流程。《决断力》一书提出了理性决策的四步流程 —— 为了提高做出最佳决策的概率，我们需要 1.拓宽选项、2. 用事实检测假设、3. 跳出自己看自己、4. 为错误决定做准备。

1.拓宽选项​

人们误以为做选择就好像考试做选择题，从三五个选项里选一个那么简单，然而世界之大，选项又何止三五？例如，一家广告设计公司在工作中会同时开展多个设计方案，并在每一轮的反馈中将有用的元素组合为最终的设计成果。这样不仅使工作效率变得更高，还也节省了决策的耗时成本。除此之外，还可以参考他人面对类似状况时做的选择的基础比率。沃尔玛的创始人 Sam Walton，就在职业生涯中一直密切关注着竞争对手的动向，从而适时调整决策。作为决策者，应要在创造更多选项和参考他人的选择中，找到最佳方案。

2. 用事实检测假设​

如果说实践是检验真理的唯一标准，那么做最终决策前的实验，也能相对准确地预估出想法能否奏效。很多公司已经从仅仅通过面试来雇佣员工，发展到要求他们通过短时间的试用期，正是为了避免面试的局限性，从而增加决策的准确性。我朋友买房前去房子里试着住了一个晚上，发现能够听到火车的鸣笛，从而花小的成本避免了大的失误。

3. 跳出自己看自己​

当决策者过于沉浸于自己的观点时，往往会忽略外部视角。所以，想要判断决策的可能结果应该去调查决策所基于的客观情况。可以考虑从更远的时间和空间的维度来衡量选项，比如安迪格鲁夫假装自己是新的 CEO 从大门进来然后砍掉内存条业务；李开复假设明天有两份报纸头条报道自己的两个选择——有情但不公正、公正但无情，继而作为领导者选择了要公正；杰夫贝索斯假设自己 80 岁回头看自己，运用"遗憾最小化框架"。

4. 为错误决定做准备​

对于决策的结果，你应该考虑到最好和最坏的两种结果，以便了解自己所处的位置。如果情况接近最糟糕的结果，你也能及时地做出反应。除此之外，还可以建立一种能使你意识到自己行为的信号，从而削弱行为的惯性，及时地纠正决策。值得注意的是，为了提高做决策的速度，贝索斯认为，决策与决策之间生而不平等，绝对不要一碗水端平 —— 可逆的决策用轻量级的决策过程。

需求分析​

• 分布式的区块链记账和智能合约系统
• 节点之间相互不大信任，但是又需要激励他们互相合作
  • 交易不可逆
  • 不依赖可信的第三方
  • 保护隐私，透露最少信息
  • 不依赖中心化的权威证明一笔钱不能花两次
• 假设性能不是问题，暂不考虑如何优化性能

构架设计​

具体模块和他们之间的交互​

基础层(P2P 网络、加密算法、存储)​

P2P 网络​

分布式系统有两种实现方式：

• 中心化的 lead / follower 的分布式，比如 Hadoop, Zookeeper 这种系统，结构比较简单，但是对 lead 要求高
• 去中心化的对等 (P2P) 网络分布式，比如 Chord, CAN, Pastry, Tapestry 算法组织起来的网络，结构比较复杂，但是更加平等

因为前提条件是节点之间不大信任，所以选择 P2P 的形式。具体到如何组织 P2P 的网络呢？一个典型的去中心化的节点和网络是这样保持连接的：

1. 基于 IP 协议，节点上线占用某个地址 hostname/port，利用初始化的节点列表广播自己的地址，利用这些初始的 hop，试图向全网 flood 自己的信息
2. 接到广播的初始节点一方面存下这个 neighbor，一方面帮助他 flooding，不相邻的节点收到后 NAT 穿墙加 neigbhor
3. 节点之间 anti-entropy 随机互相 heartbeat 发出最新的带着类似 vector clock 的信息，保证能够持续更新对方那里自己的最新信息

我们可以利用既有的库，比如 libp2p，来实现网络模块。网络协议的选择见Crack the System Design Interview: Communication.

加密算法​

在互相不大信任的分布式系统中，一笔转账如何在不泄漏自己秘密信息的同时证明这个转账是自己发起的呢？非对称加密：一对公钥和私钥对应一个”所有权”。Bitcoin 选择 secp256k1 参数的 ECDSA 椭圆曲线加密算法，为了兼容，其他链也基本选择同样的算法。

为什么不直接把公钥作为转账的地址呢？隐私问题，交易的过程应该尽可能少地泄漏信息，用公钥的哈希作为“地址”可以避免接收方泄露公钥。甚至，人们应该避免反复使用同一个地址。

具体到账本的账户，有两种实现方式 UTXO vs. Account/Balance

• UTXO (unspent transaction output) ，例如 Bitcoin，类似于复式记账的 credit 和 debit，每个 transaction 有都有 input 和 output，但是除了 coinbase 每个 input 的前面都连着上一个的 output。尽管没有账户的概念，但是取一个地址对应的所有的未花完的 output，就是这个地址的余额。
  • 优点
    • 精准：类似于复式记账的结构，让流水账非常精准地记录下所有的资产流动。
    • 保护隐私和抗量子攻击：如果用户经常换地址的话。
    • 无状态：为提高并发留下了可能。
    • 避免重放攻击：因为重放会找不到 input 对应的 UTXO
  • 缺点
    • 记录了所有的交易，复杂，消耗存储空间。
    • 遍历 UTXO 花时间。
• Account/Balance，例如 Ethereum，有三个主要的 map：account map, transaction map, transaction receipts map. 具体在实现上，为了缩减空间、防篡改，使用 merkle patricia trie (MPT)
  • 优点
    • 省空间：不像是 UTXO 那样，一个 transaction 把多个 UTXO 联系起来
    • 简单：把复杂性让给了 script
  • 缺点
    • 需要用 nonce 解决重放问题，因为 transaction 之间没有依赖性

值得一提的是 “区块 + 链” 的数据结构本质上来讲，就是 append-only 的 Merkle tree，也被称为 hash tree.

存储​

因为本身 UTXO 或者 MPT 这种结构就充当了索引，加上分布式的时候，为了让每个节点运维更加简单，一般做 data persistence 的时候倾向于选择 in-process database 随着节点的程序能够直接跑，比如 LevelDB, RocksDB。

因为这种索引并不是通用的，所以你并不能像是 SQL 数据库那样查询，这也为数据分析提高了门槛，优化时需要专门做一个 indexer 服务，比如 etherscan。

协议层​

现在我们有了可以操作的基础层后，在这层之上，我们需要一个比较通用的逻辑操作的协议层。根据这个区块链的使用需求，可以像是微内核构架那样，插拔具体的逻辑处理模块。

比如最常见的记账：在最新的 block 高度收到了一些 transaction，组织起来建立如上一层构架所说的数据结构。

为每一个业务逻辑写一个原生模块然后更新所有节点的代码不大现实，用虚拟化的方法解耦这一层？答案是能够执行 smart contract 代码的虚拟机。在互不可信的环境中，不能让客户白执行代码，所以这个虚拟机最独特的功能可能是计费。

基于 contract 的 token 比如 ERC20 和 native token 的区别，导致在不同的 token 捣腾的时候很麻烦，于是就出现了 Wrapped Ether 这种 token.

共识层​

协议层算出来执行的结果之后，如何跟其他的节点达成一致呢？有如下一些常见的激励大家合作的机制：

• proof of work (POW): 用 hash 的碰撞挖 token，耗电量大不环保
• proof of stake (POS): 用质押的 token 挖 token
• delegated proof-of-stake (DPOS): 选人民代表用质押的 token 挖 token

在激励机制的基础上，节点中谁的链最长听谁的，两群人互不待见就分叉。

同时，有这样一些一致性协议让大家达成共识（也就是大家要么一起都干，要么一起都不干）

• 2PC：大家都依赖某一个 coordinator：coordinator 问大家：要不要干？只要有人回复不干，那么 coordinator 跟所有人都说“不干”；否则都说干。 这样的依赖会导致，如果 coordinator 在第二个阶段的中间挂了，有些节点会不知道怎么办 block 在那里，需要人工干预重启 coordinator。
• 3PC：为了解决上述问题，加一个保证大家在干之前都知道所有人要干还是不干的阶段，出了错就重新选 coordinator
• Paxos：上述的 2PC 和 3PC 都依赖某一个 coordinator，如何干掉这个 coordinator 呢？用“大多数(2f + 1 里至少 f+1)”来取代，在两步中，只要大多数取得一致，最后就能取得一致。
• PBFT (deterministic 3-step protocol): 上述的做法容错率还是不够高，于是有了 PBFT。用来保证大多数(2 / 3)节点要么都同意，要么都不同意的算法，具体做法是三轮投票，每轮有至少大多数(2 / 3)节点同意，最后一轮才 commit block 。

在具体的应用中，关系数据库大多用 2PC 或者 3PC ；Paxos 的变种有 Zookeeper 的实现，Google Chubby 分布式锁的实现，Spanner 的实现；区块链中，Bitcoin, Ethereum 是 POW，新的 Ethereum 是 POS，IoTeX 和 EOS 是 DPOS。

API 层​

见 Public API choices

5 个参与方​

1. 持卡人：卡的授权用户。例如，任何拥有信用卡的人。
2. 发卡机构：向其用户发放信用卡的机构。例如，Chase、BOA、Discover 等。
3. 商户：提供产品或服务并接受信用卡支付的实体。例如，Uber、Doordash 等。
4. 收单机构：向商户提供卡服务的机构。例如，BOA 商户服务、Chase Paymentech。
5. 电子支付网络：收单机构和发卡机构的清算中心。例如，VisaNet、MasterCard、Discover、American Express 等。

Square 和 Stripe 是收单机构吗？不，它们是支付聚合商。

2 个工作流程​

1. 授权：持卡人向商户提供卡片/卡片信息，商户处理后将（卡号、金额、商户 ID）发送给收单机构。收单机构通过电子支付网络联系发卡机构。发卡机构检查信用额度和防欺诈系统，然后授权或拒绝交易。

2. 清算/结算

   1. 批处理：在营业结束时，商户向收单机构请求一批支付信息进行清算。
   2. 清算和结算：收单机构通过电子支付网络与发卡机构协调清算，发卡机构结算资金并为持卡人记账交易。