传统的钱包系统上，客户和钱包系统请求产生一个新地址时，系统会生成一组私钥及对应的地址，并存储到数据库，然后再将地址返回给客户。看起来再平常不过的行为，却牵涉到到背后云端服务的稳定性。试想，今天客户请求了一笔地址，系统也如预期的产生了，接着你马上将钱存了进去，结果钱包系统背后的云端服务发生了异常情况，导致无法服务，过了几分钟后，整个环境都恢复上线，当你再次到钱包系统查询余额，却得到0，甚至是找不到。
要确保回给客户的地址不会遗失，第一个想法就是缩短云端服务的备份时间即可，则毕竟是有极限的。看似简单的任务，实际上是很复杂的。
AMIS做为钱包系统的开发商，目标就是确保客户资产不会有安全上的疑虑，除了使用跨云备份解决上述问题外，还提供机构等级的安全性，反骇客窃盗技术，点对点资料加密等。
正面云端服务
缩短云端系统的备份时间，还是没办法解决问题，以AWS为例，RDS快照/即时点支持的最新还原点是5分钟，但你不可能要求客户5分钟后才可使用提款/存款吧？
也许你会说，可以使用Aurora的资料同步功能，备份到S3，但因为S3不支持加密，所以你的资料将会在网路上裸奔。
接着，将焦点从单一服务拉到整个云端服务来看，当你把客户资产托管在单一云端系统上更容易承受过大损失而倒闭，例如AWS在2017年就因为一位开发人员的失误而造成了大规模的服务中断，当时的S＆P500损失了近15亿美元，Azure在2018年则是因为天灾而造成硬体装置损毁，GCP在2019年则是发生了近三年最大规模的当机。
你没办法预测什么时候当机，只能做足准备。更重要的是，在数位货币这行，你该如何向云端服务商证明你的损失和支出？
解读造成tBTC紧急关闭的系统设计缺陷
为了将比特币相对庞大的市值注入到以太坊DeFi世界中，许多团队尝试去做两边跨链的转移，发行针对比特币做锚定的代币，例如imBTC，wBTC，tBTC等专案，而相对去中心化的tBTC在5/15上线
由上述可发现，倚靠单一云端平台是非常危险的。跨云备份系统是必要的，设计上必须确保提供给客户的地址不会在资料库中遗失，已备份资料如何不外泄，资料的备份又该如何管理，又该如何监控备份资料是否完善等。
跨云备份服务的产生
为了确保所有提供给客户的地址不会遗失，我们使用了地址池的概念，也就是预先生成地址，转化其备份，然后就可以确保此地址的使用性。
备份系统会从资料库中输出未备份的资料档案，将其加密后上传到第三方云端存储服务上（存储加密的私钥则是存放于Vault中，管理者可以通过放置不同的帐号或令牌）另外，档案加密也可确保档案在传输的过程中被侧录或资料外泄时，也无从解开，避免避免自家人监守自盗的情况发生。
备份档案的设计上，可以用差异备份又或者全部备份。差异备份的优点是速度较快，缺点是档案过多，需要定期压缩，并且需要存储上次备份的位置。全部备份优点为还原和验证的逻辑多个简单，资料保存上可能仅需最后10笔资料即可，缺点就是备份时间较久。
跨云备份档案管理
现在许多云端服务商都有提供保留原则政策的设定，主要是避免管理员操作失误，符合法规控制管，在时间上可以设定10年甚至更多，来确保资料不会无故消失。
在云端服务商上启用审计追踪
这是一个非常重要的功能，开启后我们可以知道云端上的档案今天被谁做了什么操作，举凡读取，下载，编辑，增加新权限等都一览无遗，当发生不可预期的错误时，可以快速找到问题并解决。
监控备份资料档案
监控已备份的地址数量与过去几秒到几分钟的流量是非常重要的，做为钱包系统服务商，我们可以利用过去的数据来调整地址池的水位，以符合客户的需求。
定期验证在云端服务上的备份档案
确保档案是正确可还原的，除了使用档案验证码作为条件外，也将资料实际还原到资料库中，确保这些档案都没有问题。
系统架构
从地址格式探讨Bitcoin和Ethereum的差异
Bitcoin和Ethereum在许多方面有着截然不同的设计，这篇文章会从地址格式出发，比较两者在交易格式以及身份认定上的差异，透过这些差异了解两套系统在设计哲学上的不同之处。由于篇
原创文章，作者：掘金K，如若转载，请注明出处：https://www.20on.com/112615.html
