| Summary || Products || Cryptography || Fusion || KeeeX.Js || Verifier || KeeeX Chain || Digital Identity Management |
¶ Usage of EVM blockchains
KeeeX utilizes a semi-public EVM blockchain for various operations that require online interoperability and auditability, called "KeeeX Chain".
It is based on geth, and the core nodes are operated by KeeeX as a Proof of Authority (PoA) blockchain.
We refer to it as semi-public because while it is publicly accessible for read operations, only vetted services are allowed to perform write operations.
By leveraging both the capabilities of the blockchain to propagate its state, the ability to verify input signatures, and the EVM's capacity to validate calls, we provide a secure environment that fosters trust among all parties involved.
Additionally, we combine it with keeexed file references to store dynamic properties bound to specific data/files without disclosing the said data, while maintaining a strong cryptographic link between both.
¶ Writing permission
As with most EVM blockchains, writing operations require "gas" to be accepted by a node.
The KeeeX Chain does not distribute gas as a resource to actual end users and provides no means for trading it outside of KeeeX.
This could lead to trust issues, particularly because the digital identity used to sign a transaction is an essential component of the trust model in such a blockchain.
To retain this crucial property, we developed a proxy Smart Contract that can forward regular Smart Contract calls directly using the blockchain's EVM.
While such an approach would be unusual (and costly) on a gas-backed EVM, since we're retaining control over write operations and limiting the scope of KeeeX Chain, it is not as significant a concern.
The implemented workflow enables end-users to effectively digitally sign calls to Smart Contracts without incurring blockchain "gas" costs.
The effective Smart Contract should be configured to trust either the actual caller (who would have spent gas while signing the transaction) or the address provided by the proxy, which has been verified within the EVM environment itself.
In the first case, the trust in the signatory is implicit due to how the blockchain operates.
In the second case, the trust comes from the address of a known "proxy" Smart Contract, whose sole purpose is to unwrap a Smart Contract call block, validate the digital signature associated with it, and forward it to another Smart Contract.
This proxy Smart Contract is designed to mitigate the following risks:
- replay attacks
- forwarding the same block to an unintended Smart Contract
- allowing invalid signed calls to proceed
Since this validation is performed publicly within the EVM transaction, third-party observers can trust that the effective Smart Contract call was indeed signed by the expected signatory, rather than relying on implicit trust from a closed intermediate service.
At the EVM level, this requires the effective function call to take the effective caller address as its first parameter.
If a standardized API does not permit this restriction, writing a small intermediate Smart Contract to check for the caller's address and forward the actual call will resolve the issue.
The benefit of performing these checks transparently from within Smart Contracts, rather than relying on trusted third-party services to relay operations, is that the full chain of trust can be audited.
This includes verifying the authenticity of the caller and ensuring that the rules applied allow or forbid an operation from occurring.
¶ Control of the block-creating nodes
As a Proof of Authority EVM blockchain, only nodes operated by KeeeX are able to create new blocks.
By design, this does not imply that KeeeX can create fake transactions from users, as these always require an actual end-user signature, either directly or indirectly.
The primary concern in such a scenario is that any actor controlling all the authority nodes would theoretically be able to prevent a third party from making write operations on the blockchain, effectively silencing them.
This is an issue in the context of a public blockchain, but not in a corporate situation.
KeeeX operates KeeeX Chain in that way specifically to restrict write operations to authorized services, which means that no random write operations can occur.
Instead, only trusted and authorized third parties, likely under some form of contract with KeeeX, are allowed to make additions to the blockchain.
While this concern is valid, it can be mitigated in a non-technical manner.
Specifically, any data written to the blockchain cannot be removed, even by someone controlling all the authority nodes, due to the presence of external nodes that replicate the most recent state of the blockchain.
These external nodes are unable to create new blocks but will replicate the current state of the blockchain and allow detection of any manipulation of existing data.
This ensures that the integrity of the blockchain is maintained, even if all authority nodes are compromised.
¶ Use cases
KeeeX worked on a few use cases that leverage a public Smart Contract-based ledger such as KeeeX Chain:
- Dynamic document property: an existing file with a fixed identifier can have dynamic properties attached to it, such as ownership, state, confidentiality level, etc.
These properties can change over time independently of the actual data attached to the identifier. - Revision history: provides a trail of trackable updates for a given document.
A typical application would be a legally binding contract seeing many revisions. - Implementing complex rules of transfer and actionability: some digital documents can be attached to actual effects in the outside world in one form or another.
An example of such a document would be a bill of lading, representing the authority of its holder over a given set of goods.
This kind of document can have complex restrictions attached to them, such as time limits, limited transferability, fallback solutions, etc., that can benefit from being publicly auditable and enforced by code.
Although this page will not delve into the details of how these are implemented, here's some information:
- Confidentiality is preserved at all times. The actual data referenced (keeexed files with their IDX) are never transferred on any public ledger.
- It is impossible to alter the link between a file and its associated ledger: altering the reference to the ledger by pointing somewhere else would break the keeexed file, and the ledger itself uses the keeexed file's unique IDX, effectively creating a cryptographic bidirectional link between them.
- All dynamic content remains publicly available and updatable as long as KeeeX operates.
For future-proof storage, any partner or third party is able to create a copy of KeeeX Chain, effectively containing all recorded transactions.
While the transactions themselves only contain minimal data and references, once confronted with the associated keeexed files, a third party would be able to rebuild the whole data.