区块链入门

从技术特点上,区块链一般被认为具有:

  • 分布式容错性:网络极其鲁邦,容错 1/3 左右节点的异常状态。
  • 不可篡改性:一致提交后的数据会一直存在,不可被销毁或者修改。
  • 隐私保护性:密码学保证了未经授权者能访问到数据,但无法解析。

随之带来的业务特性包括:

  • 可信任行:区块链技术可以提供天然可信的分布式账本平台,不需要额外第三方中介机构。
  • 降低成本:跟传统技术相比,区块链技术可能带来更短的时间、更少的人力和维护成本。
  • 增强安全:区块链技术将有利于安全可靠的审计管理和账目清算,减少犯罪可能性,和各种风险。

分布式共识

  • Pow
  • Pos
  • DPos
  • Casper

处理性能

  • 提高单节点硬件性能
  • 高频交易放到链外(如闪电网络)

扩展性

  • 放松对每个节点必须参与完整处理限制,但至少部分节点要能合作完成完整的处理,已在超级账本上使用,同时尽量减少核心层的处理工作。
  • 联盟链模式下,可以专门采用高性能节点作为核心节点,用相对较弱的节点作为代理访问节点。

系统安全

  • 立法
  • 漏洞
  • 大数据公开透明
  • 合约约束

数据库和存储系统

特点

  • 大量写操作、hash 计算和验证操作

  • 目前用 LevelDB、RocksDB 等键值数据库,具备高随机写和顺序读性能

  • 但是随机读就比较差

  • 需要针对区块链场景设计对于数据库

可集成性

与中心化业务系统共存

其他问题

  • 智能合约的合法性、安全性、可执行性
  • 如何将现实中的合约和条约对应为电子合约
  • 分布式系统的伸缩可靠性和数据迁移
  • 对存储系统新的挑战,特别是性能

区块链

应该是大家公认的一个 API,减少各个社会单元对接成本。

一致性

挑战

  • 节点之间的网络通讯是不可靠的,包括任意延迟和内容故障
  • 节点的处理可能是错误的,甚至节点自身随时可能宕机
  • 同步调用会让系统变得不具备可扩展性

目前解决方式

将可能引发不一致的并行操作进行串行化,就是现在计算机系统里处理分布式一致性问题的基础思路和唯一秘诀。

要求

  • 可终止性(Termination):一致的结果在有限时间内能完成
  • 共识性(Consensus):不同节点最终完成决策的结果应该相同
  • 合法性(Validity):决策的结果必须是其他进程提出的提案

带约束的一致性

实际上,越强的一致性要求往往意味着越弱的性能。

强一致性:

  • 顺序一致性
  • 线性一致性

《无论何时我们恋情都是10厘米》

老师 —— 现在摸不着头脑,到了迷茫的时候这些会有用也说不定。

现在理所当然度过的每一天,也会有结束的时候。就算是毫无感觉而度过的每一天,也可能变成再也不会到来的无可替代的时光。名为今天的一页,这一段场景,相互联系,相互交叠,成为故事

极简OffetHeight/ScrollHeight/ClientHeight

图片占位符最佳实践

一般情况下,浏览器在解释 HTML 文档流过程中,遇到img等资源标签,会马上发起资源请求获取。但是对于图片这种需要占用空间的元素,浏览器并没有一个默认机制来提供占位。

 所以可能会有童鞋直接使用 UED 原图的大小来作为默认图片大小占位,在移动端场景,不同移动设备宽度不一致,图片需要适配设备分辨率,用像素显得灵活性较差。

对于移动端响应式,一般有两种方案:

  • 通过rem来适配不同设备的宽度
  • 利用padding-bottom的特性来”撑开” 占位空间

使用 Rem

对于现代移动设备来说,直接使用rem是一个不错的方案。如果需要在 PC 使用,需要考虑一下兼容性,https://caniuse.com/#search=rem

使用 padding-bottom

利用padding-bottom根据当前元素width作为百分比参考,只需要设定占位元素宽度以及宽高比例(height/width)即可。padding 为 css2.1 标准,可兼容至 IE4,基本无需考虑兼容性问题。

外边合并

只有普通文档流中块框的垂直外边距才会发生外边距合并。行内框、浮动框或绝对定位之间的外边距不会合并。由于margin merge使用条件十分有限,建议使用这种规则时候,需要多考虑以后维护会带来的问题(如布局类型改变带来的布局问题)。