CoinXP Newsletter Mar. 4 - 15
Technical Dev by Architect Weijia
In the past few weeks, we focused on another critical part of securing our CoinXP MainNet, credential ids and keys management. These ids and keys include crypto wallet passwords, crypto account public/private keys etc. The goal is very clear: we do not want to have any credential id or key stored in any storage of our service, we do not want to manually create or management any credential id or key, and we do not want to grant access to create/retrieve requests unless necessary. To accommodate all the requirements, we adopted AWS Secret Manager as the one and only source for all of our mission critical credentials. Keys are created/retrieved with SDK APIs only when absolutely necessary. To harden the security part, only services from the virtual private cloud with correct AWS account credentials can access the secret manager endpoint. This is the defense against secret hacking. Since secrets management is the central focus around security. There are also many other techniques we put in place to ensure even a hack was able to break into our private cloud, he/she will not able to get access to our credentials stored in AWS Secret Manager. This is done with the help of AWS fine grained resource permission control with AWS roles, policy and dynamic delegation. Furthermore, the entire tech stack is automated with Kube2Iam in our architecture such that any worker (pod in our Kubernetes cluster) being brought up are automatically assigned with the correct permissions, roles, and polices. Therefore leaves no room for human error or manipulation.
Research by Research Scientist Wuwei
We recently studied a paper on the challenges and pitfalls of partitioning blockchains by Fynn and Pedone because it also has implications on the scalability of decentralized exchanges. It is well known that scalability has become the main challenge out of the blockchain trilemma after explosive growth of cryptocurrencies and blockchains in the past decade. Sharding is proposed as a promising technique to solve the blockchain scalability issue. Basically, sharding is to partition the processing power or states of a distributed system into multiple subsystems. In a perfectly partitioned system, all transactions can be executed locally within a shard and the load among shards are balanced, then the performance scales with the number of shards. In reality, perfect sharding can rarely be achieved, especially for complex systems as blockchains. Therefore, partitioned blockchains inevitably need to deal with cross-shard transactions, which are usually solved in two ways: (1) the involved shards coordinate and execute the transaction in a distributed fashion or (2) move the necessary state to one shard so that the transaction can be execute locally. In either case, cross-shard transactions incur extra processing power, storage and network bandwidth. Consequently, a poorly sharded system sometimes may perform worse than the original system. It is crucial to partition a system effectively to minimize cross-shard transactions. If we transform a blockchain into a directed-graph with vertices as accounts and edges as transactions between accounts, an effective partition needs to minimize the number of edge-cuts and balance the load (number of transactions) among shards.
Fynn and Pedone investigated five partitioning algorithms based on the real data from Ethereum. The algorithms include (1) hashing, (2) Kernighan-Lin algorithm, (3) METIS, (4) R-METIS, and (5) TR-METIS. Each of the algorithms is applied to partition Ethereum into 2, 4, and 8 shards. It is found that dynamic edge cut becomes worse as the number of shards increases. There is a clear compromise between edge-cuts and load balance, .i.e., it is unlikely that Ethereum can be partitioned with minimal edge cuts and balanced load at the same time. No algorithm stands out as the clear winner in both aspects. For example, hashing algorithm results in excellent load balance but poor edge cuts. Conversely, METIS achieves excellent edge cuts but poor load balance, and R-METIS and TR-METIS achieve more balanced results between edge-cuts and load balance. Furthermore, Ethereum needs to be partitioned periodically to maintain performance. Based on the research, sharding itself is an expensive operation and cross-shards transactions can incur significant extra cost including processing power, storage and network bandwidth even for a simple configuration of 8 shards. Therefore, the real Ethereum 2.0 update with 1024 shards will be much more complex and challenging.
One interesting information from the paper is that effective sharding is hard to achieve because some accounts are very active with frequent transactions among them and some accounts are dormant with none or few transactions after account creation. I’m thinking instead of focusing on effective sharding with minimal edge cuts and balanced loads, we can partition the system based on transaction frequencies like a CPU caching system, active accounts are treated with highest priority regarding processing power, storage, network bandwidth and inactive accounts have lower priority. We will do research further and write more in the future about this topic.
- Enrique Fynn, Fernando Pedone, Challenges and pitfalls of partitioning blockchains, https://arxiv.org/abs/1804.07356, 2018
Operation by Kay
As CoinXP mainnet is going live soon, we are actively exploring future collaborations with general public chains. As a vertical public chain focusing on transparent trading, CoinXP supports each general public chain by listing its native and ecosystem tokens on the decentralized exchange, hence enhances the public chain ecosystem to grow stronger with their tokens’ circulation.
Recently we have signed memorandum with Harmony.one, a next generation high performance blockchain protocol aiming to serve as the global consensus platform for 10 billion people in the future world. CoinXP will collaborate with Harmony to enhance the strength of both ecosystems and build a close loop of the value transfer through eco-token trading.
We would be happy to offer our trading infrastructure to more public chains with the vision of building a transparent and free token exchange ecosystem.
Follow our English Community for more to come,
Whitepaper Download: http://www.coinxp.io/public/CoinXP_Whitepaper_Public.pdf
Eat Pray Trade: https://v.qq.com/x/page/u0776ttvp8m.html
Twitter: @coinxpofficial https://twitter.com/CoinXPofficial
Subscribe to ANN: https://t.me/CoinXPChain
Telegram Official: t.me/cxp2dm
Testnet Demo by CTO Hua CHEN in EN: