The Kima Platform
Last updated
Last updated
The Kima platform provides seamless cross-chain interoperability without token wrapping.
To avoid creating synthetic (“wrapped”) tokens on each chain, Kima maintains liquidity pools on each integrated layer-1 blockchain (e.g., Bitcoin, Ethereum, Terra, and Solana). A user who wishes to send an asset (e.g., USDC) from one chain (e.g., Ethereum) to another (e.g., Solana) will send USDC to Kima’s USDC pool on Ethereum and withdraw USDC from Kima’s USDC pool on Solana.
The core of the Kima platform is the Kima blockchain which monitors and synchronizes assets across multiple existing layer-1 blockchains.
The Kima blockchain uses committee-based consensus. Each committee consists of a rotating set of “wardens” whose role is to ensure the asset pools remain in sync, withdrawals from a pool on the destination chain are only authorized when a corresponding deposit has been confirmed on the source chain.
Kima wardens control the asset pools on the destination chain through the Threshold signature schemes (TSS). Security is strengthened by running the wardens inside a Trusted Execution Environment.
Threshold signature schemes (TSSs) allow a group of participants (“cosigners”) to securely generate and control the secret signing key for a digital signature scheme, such that a certain threshold (e.g., 7-out-of-10) cosigners must participate in the signing protocol to generate a signature.
Specifically, a threshold signature scheme consists of two protocols - (1) Distributed Key Generation and (2) Distributed Signature Generation.
The Distributed Key Generation protocol creates private “key shares,” where each participant holds a single share and a single public verification key for a digital signature algorithm (either ECDSA or ED25519).
The Distributed Signature protocol takes each participant’s key share and a (public) message and creates a digital signature on the message that will verify under the verification key created during the key generation protocol.
The “threshold” property comes from the guarantee that there is a fixed threshold (e.g., $t$-out-of-$n$) such that an adversary who corrupts up to t participants in the protocol (and learns their private key shares) learns nothing about the underlying secret key. In particular, an adversary who corrupts $t$ or fewer participants cannot generate a new signature on any message.
Threshold Signature protocols can be extended to arbitrary authority structures. For instance, there could be a set of $n_1$ highly-trusted signers (e.g., signers that have undergone KYC and have a real-world reputation at stake) as well as a larger set of $n_2$ anonymous signers that are chosen dynamically through on-chain staking. The TSS could then be built so that it needs both $t_1+1$ public signers AND $t_2+1$ anonymous signers to participate in order for a statement to be signed. Any adversary then who does not control this learns nothing of the underlying secret key and is unable to forge signatures.
Furthermore, TSS protocols can use Proactive Secret Sharing to periodically re-randomize the shares of the secret key. If an adversary compromises a few of the wardens and so learns a few shares of the secret key before the re-randomization, this knowledge will not help it learn shares of the secret key after re-randomization. Essentially, this means each re-randomization causes the adversary to have to restart from zero in its efforts to learn secret shares. Thus, as long as the adversary isn’t able to learn the full secret key between any pair of re-randomizations, it will never learn the secret key or be able to make new signatures.
Proactive Secret Sharing strictly increases the security of the system, protecting against an adversary who is able to compromise some nodes but is never able to compromise above a certain amount within a certain time window.
Threshold signature schemes exist for ECDSA and ED25519. In addition to rigorous theoretical proofs of security, TSS schemes have been widely implemented. In fact, professionally audited, open-source TSS libraries are available from Axelar, ZenGo, ING bank, Binance, Thorchain, Ren, and Coinbase. Collectively, these TSS implementations are currently used to custody billions of dollars worth of tokens across multiple blockchains.
Although attacks are common in the DeFi space, there have been no reported attacks that have exploited a Threshold Signature Scheme.
Trusted Execution Environments (TEEs) provide hardware-based security where secrets can be stored and code can be executed in a secure and verifiable manner. The key properties of a TEE are:
Privacy: Data processed inside the TEE cannot be accessed by external programs, system administrators, or attackers who have physical access to the machines.
Transparency: TEEs can “attest” to the code they are executing, thus the output of a TEE can be publicly verified.
The most common TEE is Intel SGX which is available on a wide variety of Intel CPUs. Microsoft Azure supports Intel SGX in its cloud instances.
It is possible to use TEEs to bring privacy to the blockchain. In almost all blockchains, every transaction is public. However, it is possible to make transactions private by running all nodes inside TEEs. This not only prevents malicious behavior by operators but even allows all transactions to be encrypted (except when inside the TEE), keeping transaction details hidden even from the operators themselves. This has been done in practice: both the Secret Network and Oasis Cipher Paratime use Intel SGX to facilitate private smart contracts on Cosmos-based blockchain.
TEEs can also significantly improve security by holding keys, or shares of keys, inside of the TEE. For instance, the Avalanche Bridge implements a 3-out-of-4 threshold signature scheme inside Intel SGX enclaves. While transactions remain public, this dramatically reduces the trust in the (anonymous) bridge “wardens” by generating and storing each warden’s key share inside an SGX enclave. Using this combination of TSS and SGX, the Avalanche Bridge wardens are custoding over $5.7B worth of assets on the Ethereum blockchain.
Intel Skylake, one of the CPUs that supports Intel’s Trusted Execution Environment SGX
Although Intel SGX is very powerful, it is not a panacea – there have been several high-profile attacks against SGX enclaves, and even in the absence of attacks, relying on Intel for security provides an unwanted and unnecessary point of centralization. Nevertheless, SGX dramatically increases the difficulty of attacking a system.
Kima does not rely on the security of Intel SGX to maintain the privacy or safeguard its assets. Instead, Kima uses SGX to complement the security of its system. Kima wardens run the threshold signature scheme inside an SGX enclave. Thus the TSS key shares are not directly accessible to the wardens or system administrators. Instead, the key shares are held inside SGX enclaves, and the entire multiparty key generation and signing protocols are run inside the enclaves. This strictly improves the security of the underlying threshold signature scheme. In a t -out-of-n threshold signature scheme, security holds as long as no more than t wardens collude to subvert the protocol. When the TSS protocol is run inside SGX, to break security t+1 wardens would need to first break the security of SGX and then collude. Breaking SGX, though not impossible, is very challenging and typically requires physical access to the host machine and significant expertise, significantly raising the barrier to entry for a would-be malicious warden. Thus by implementing the threshold signature scheme inside an SGX enclave, Kima can significantly boost security with only a negligible loss in performance.
