随机数|读懂Dfinity：去中心化云计算平台+高性能区块链网络( 六 )

总而言之，Portal 作为一个直播平台，最关键和难处理的视频分发以及存储都是选择用的 Livepeer，和 ICP 没有关系。Portal 与 ICP 的关系仅仅是部分简单的数据使用 ICP 存储以及修改。这实际上就是 Portal 抱 ICP 的大腿，在宣传其生态的同时，也能给自己打上这么一个 ICP 平台第一直播网站的标签。
ICP 到底强在哪里？用户角度抽象的来说，ICP 已经足够“快”了，以至于用户都无法感知到它在后端是区块链。可以说 ICP 和其他云平台在使用上是感受不出区别的。在传统区块链，比如以太坊上部署智能合约的应用会让用户体验非常差，由于要各种确认交易支付手续费，以及网络确认的缓慢。但是在 ICP 上，由于其 POS + 随机数的共识协议，TPS 高，同时有数据结构的各种优化，可以支撑起流畅的用户体验。因此才有各种应用的 ICP 版，比如 LinkedUp、Distrikt。
开发者角度

读取数据：目前普遍是在 250ms 以下。这个速度基本上是人按下鼠标并放开的时间长短，人基本体验不出来。
写入数据：因为需要达成共识，所以比读取需要更多时间。目前通常是 2-5 秒。与 BTC 或 ETH 相比，这要快了无数数量级。与中心化云平台相比，这可能看起来很慢，但实际上这个速度是还可以接受的。
目前 Canister 是单线程的，之后 Canister 如果升级成多线程，那读取和写入的速度也能大幅度提升。从开发应用的角度而言，这个速度不算快，但是对于做一个普通的 WebApp 绝对够用了。

区块链角度ICP 的架构设计，类似云平台，有更多的节点意味着节点与用户之间的物理距离可能更短，网络会更快，可以做到“更多节点 = 更多子网 = 更大的网络容量 = 应用更高的性能”。具体的技术实现可以参考这篇详细的博客：https://medium.com/dfinity/a-technical-overview-of-the-internet-computer-f57c62abc20f。
ICP 的缺点https://dfinity.org/roadmap/
Canister 优化目前，Canister 能给其他 Canister 发更新请求。如果有 A、B、C 三个 Canister，A 要通过 B 去和 C 交互，那么就需要 A 发更新请求给 B → B 发更新请求给 C → C 接收请求。但是问题就是这样的响应时间大概需要 4 秒，对用户体验来说很慢。如果是跨不同子网的话就可能更慢。如果要是有 10 个 Canister 需要交互的话，那一个请求需要 20 秒就是很恐怖的。在 ICP 里有查询请求，性能是很快的，一次只需要 200 微秒，但是跨 Canister 的链式请求没有原生支持。所以为了避免未来跨应用间请求的性能问题， ICP 需要更新，提供原生的高性能 API。
还有一点就是目前 Canister 的执行是单线程的，虽然 Canister 中可以“打包”执行一些指令，但是如果支持多线程的话，也会大大改善性能。但是这些更新和生态中的其他部分息息相关，比如 ICP 所支持的 Rust SDK 也和 Rust 这门语言自己的生态发展息息相关，所以技术上或许需要多方努力才能改进完成。
自定义域名目前在 ICP 上部署的 APP 的域名都是 Canister 的 id 在加上 ic0.app，比如 https://ja7sy-daaaa-aaaai-qaguq-cai.raw.ic0.app。虽然开发者可以自行通过购买其他的域名来重定向到 Canister 的长域名，但是在使用过程中，那么长的域名还是会对用户体验有很大的影响。同时 Dfinity 论坛里的开发者以及他的客户也对这个问题很有意见，认为是开发过程中的巨大阻碍。这或许是很小的一点缺陷，但是也能展现出 Dfinity 还需要努力完善这些细节。除此之外，在与 Dfinity 的开发者交流之后得知，在 ICP 上创建账户会有两个账号，这对于区块链应用使用者来说是很反直觉的，所以应用开发者通常会单独再创建一个账号。这也是 Dfinity 在用户体验上能提高的地方。