為什麼錢包地址的備份如此重要？
使用地址池與跨雲備份
選單
使用地址池與跨雲備份
當網路發生堵塞，交易遲遲不上鏈會發生什麼問題呢？使用者或是錢包服務提供商，該如何減少這類情況的發生？本文將針對上述問題做探討，並且介 紹 AMIS Wallet Service 目前針對發送交易的使用體驗所做的優化。
下週比特幣網路將迎來誕生以來的第三次減半 (halving)，也就是說台灣時間約莫下週二早上，比特幣礦工的獎賞 (mining reward) 將由每個區塊 12.5 BTC 減少至 6.25 BTC，減半議題在幣圈早就不是什麼新聞，我們可以很常在社群網路上看到很多貼文闡述著比特幣減半將迎來新的一波大牛市，而目前這波“減半行情”確實也將幣價拉抬了不少。
然而本文將從另一個角度去探討比特幣的減半，究竟從一個虛擬貨幣服務商，到持有比特幣的每個人，有沒有除了價格以外，安全性上值得我們多加留意的？
在目前的實務上，最常使用的同態加密是 Paillier cryptosystem。是一種非對稱式加密：會有一組公鑰用來加密，一組私鑰用來解密。並且在這情況使用的是 RSA 模組。更具體的說就是公鑰有兩個參數決定
在這篇短文，我們簡介同態加密( homomorphic encryption) 的基本概念，以及應該具有的密碼學性質。
之後會在系列文章給予兩個例子 (asymmetric algorithm)：Paillier 和 C.L. homomorphic encryption。並且在例子 Paillier 解釋為何滿足同態加密的特性。在 C.L. homomorphic encryption 我們點出在應用上為何它比 Paillier 更優越之處。
Key management plays a significant role in blockchain technology regarding digital assets protection. Practically speaking, losing private keys leads to great losses. Improper key management and poor system implementation may increase the risk of asset being transferred maliciously. Take an extreme case that happened before as an example, a principal died suddenly and no one was able to recover keys so that the whole asset was frozen. To solve these problems, experts therefore propose threshold cryptography to reduce the risk of key management.
在前面的文章中，我們介紹過 LibraSwap，但實際上透過 Libra SPV，我們可用於搭建 Libra 與 Ethereum 之間的橋樑，稱做 LibraBridge。利用 SPV validation 實作跨鏈的代幣交換不是新的創舉，過去有許多項目利用這個方法來橋接兩個不同的鏈上資產，如下。SPV 是一種用於輕節點驗證交易的方法，透過智能合約的協助，我們可以在合約上驗證來自 Libra 的交易。
In the previous article, we explain the concept of the LibraSwap. Next, we will introduce LibraBridge, which can be used to connect Libra with Ethereum by Libra SPV method. The idea to leverage SPV validation to implement cross-chain transfer is not new. It’s already done by several projects listed below. SPV proof is a way for light client to verify if interested transaction happened on the blockchain. With the help of smart contract, Libra SPV proof can be implemented on Ethereum. Namely, we can verify a Libra transaction through smart contract, along with some external information.
Generally, you need to have a client when connecting to the blockchain network. There are different types of nodes: full node, light node, mining node and relay node. In this article, we will focus on how a light client node works because not everyone can run a validator node (full node) in Libra since it is a permissioned blockchain. Instead of fully verifying all transactions and blocks, light clients only need to download block headers and verify if interested transactions are included in the block. Light clients are run by devices that do not have huge computation power and bandwidth.
Finally, AWS made changes in the AWS identity APIs to recognize Kubernetes pods, so each K8S Pod can have specific IAM Role to acquire proper permission to access AWS cloud resource (This feature called IRSA). For the AWS Hosted K8S (A.K.A. EKS), official provided detail document and blog post to demonstrate how to achieve it, but there is still not many online resource to talk about how to enable it for Self-Hosted K8S in AWS, hence, I write this post to go through how to enable IRSA in Self-Hosted K8S.
