Skip to main content

Technical Details

Validator Stack Architecture​

The architecture of the JSC “Validator Stack"1 was designed to allow the adoption of the latest developments and changes to the Ethereum execution and consensus protocols whilst also allowing for a permissioned set of validator clients and a basic level of compliance.

JSC Validator Stack Architecture

JSC Validator Stack Architecture

A JSC Validator Stack consists of 3 components: the execution client, the consensus client, and a validator client. The execution client and the consensus client are standard Ethereum software components and may be operated separately by those who have not been designated a Validator Client Operator seat, mostly in a “read-only” capacity on the JSC network.

  • Validator Client

    • Entities running validator clients are deemed the true “stakers” on the network. JSC has set a high token threshold as well as a whitelist for those who are allowed to run a validator client.
    • The protocol rewards them for securing the network and maintaining consensus.
    • The main role of a validator client is to propose blocks, attest to the validity of blocks, and provide the ability for light clients2 to sync with the network.

  • Consensus Client

    • Manages the “beacon” state for the validator client with the proof of stake consensus protocols - this includes fork choice and state finality.
    • Coordinates multiple validator clients, passes messages, and handles duty assignment (such as block proposing duties).
    • Exchanges consensus messages in a peer-to-peer (P2P) network with other consensus clients.

  • Execution Client

    • Receive and gossips pending transactions over its P2P network of other execution clients.
    • Packages pending transactions into payloads to be proposed by validator clients.
    • Executes blocks in the Ethereum Virtual Machine and updates the blockchain state.
    • Exposes the JSON-RPC API for blockchain users to interact with the blockchain (i.e., submit transactions, read the blockchain via a blockchain explorer, etc).
    • Holds logic defining the Ethereum Virtual Machine (EVM).

Consensus Protocol​

JSC is an EVM blockchain network powered by a proof of stake (PoS) consensus protocol. The blockchain is validated by a selected set of 21 Validator Client Operators running validator clients, maintained onshore in Japan according to stringent hardware and software criteria set by the Japan Smart Chain Foundation (JSCF).

JSC applies proof of take consensus where the permissioned set of validator clients are routinely assigned consensus duties, and rewarded for performing them correctly and in a timely manner, and are penalised for either missing their duties or provably doing them incorrectly.

Mizuhiki Suite: Use of Decentralised Identifiers and Verifiable Credentials​

Mizuhiki is the universal identity protocol optimized for the JSC network. The core of this suite revolves around “Mizuhiki ID”, which enables JSC customers to be issued a simple verifiable presentation (VP) or soulbound token (SBT) to their blockchain address by a trusted Mizuhiki Attestor.

Mizuhiki Attestors are a Japan-sovereign network of compliant and licensed Mizuhiki Suite attestors. They establish a "root of trust" that binds the real identity and digital identity of individuals, institutions, and other entities. Mizuhiki Attestors can issue verifiable credentials to a user's Decentralized Identifier (DID). The personal data contained in a verifiable credential is never stored on-chain and never visible to any JSC client operator. JSC customers are able to present a zero-knowledge proof to verifiers to prove their eligibility to perform certain on-chain actions, without disclosing any private information beyond the validity of their verifiable credential. This may take the form of a verifiable presentation and/or soulbound token.

Verifiable credentials result from a W3C Recommendation, and is designed to be complemented with decentralized identifiers for issuing, holding, presenting, and these credentials3. Credentials could include various documents, such as university diplomas, driving licenses, identity documents, and so on. Verifiable credentials can represent various documents, such as university diplomas, driving licenses, identity documents, and so on. The Mizuhiki ID toolkit in particular provides a verifiable presentation4 called “Mizuhiki Verified” that demonstrates a “proof of KYC” on-chain: this claims that the user controlling a particular JSC address has undergone the specific KYC and screening procedure in Japan, enabling them to interact with regulated on-chain applications.

Mizuhiki’s use of verifiable credentials, verifiable presentations and soulbound tokens (which may be thought of as a type of verifiable presentation), is enabled by the use of Decentralised Identifiers.

Decentralized Identifiers (DIDs) are digital identifiers recommended by the W3C working group specifically for the verifiable identification of subjects in a decentralized environment.

Each DID is structured as a URI containing information on methods for resolving and verifying the documents referred to by the identifier.

A simple example of a decentralized identifier (DID)

A simple example of a decentralized identifier (DID)5

The Mizuhiki Suite features its own DID Method, which conforms to W3C specifications and is referred to as the "Mizuhiki DID" or "Mizuhiki DID Method." This method encompasses the syntax, resolution, verification, and authorization processes for Decentralized Identifiers (DIDs) and DID documents that start with the prefix did:mizuhiki.

A Mizuhiki DID registry is a smart contract registry that records the unique DIDs and DID Document metadata of users who have undergone KYC under Japan’s Act on the Prevention of Transfer of Criminal Proceeds.

KYC is performed by a "Mizuhiki Controller", which must be a registered JPKI Service Provider[15].

End-user Mizuhiki ID procedure​

Mizuhiki ID end-user flow

Mizuhiki Protocol end-user flow

The end-user flow for completing the Mizuhiki ID procedure, including the process for obtaining a “Mizuhiki Verified” address on JSC, involves the following steps:

DID Generation and Registration​

  1. The user starts the Mizuhiki Identification process with a Mizuhiki Controller. (“Controller”), providing the necessary documents for identity verification. A Mizuhiki Controller conducts all identity and document checks completely off-chain with the goal of preserving user privacy.

  2. The Mizuhiki Attestor generates and registers a DID on-chain via the Mizuhiki SDK (in development).

Mizuhiki Verified Soulbound Token​

  1. Using the Mizuhiki SDK or application, and once authorized as the owner of the respective DID, the user can issue a "Mizuhiki Verified" soulbound token (SBT) to their JSC address.

  2. The SBT is issued by a Mizuhiki Controller , and is non-transferable but burnable by the Controller and/or the user. Importantly, the soulbound token does not contain any personally identifiable information (PII), including the DID.

Verifiable Credentials​

  1. A user may want to use verifiable credentials to manage other credentials. In this case, a user must request a credential from a trusted entity - such as a university or registered institution - that supports the Mizuhiki DID method and the W3C Verifiable Credential specification. We refer to such an entity as a “Mizuhiki Attestor”.

  2. After receiving a VC request, the Mizuhiki Attestor may issue verifiable credentials to the user. Verifiable credentials are mapped to the user’s Mizuhiki DID off-chain, in a completely private and secure manner. The verifiable credential is able to be accessed by the DID subject by completing authorization to a verification method contained in their DID’s verification methods.

A verifiable credential may contain a set of claims, such as date of birth, GPA, or residential address. A user may only want to forward a subset of these claims to the verifier, i.e., a verifiable presentation. This means the user could reveal their age bracket without revealing their birthdate, or their residential area without disclosing their full address.

Verifiable Presentations​

  1. Users may generate and issue on-chain-compatible verifiable presentations to their JSC addresses or other applications on JSC - perhaps in the form of a soulbound token - based on their verifiable credentials via the Mizuhiki SDK. Verifiable presentations may be issued by the user holding the verifiable credential or the issuer of the credential. On-chain VPs should not have any personally identifiable information contained in them, including the DID itself. Verifiable presentations are also available off-chain and in this case may include PII.

Compliance & Risk Management Rule Engine using SBTs/VCs​

If the user wants to engage in a regulated activity on JSC (e.g., a financial transaction), the user can present their SBT/VC (and hence their eligibility) to the JSC application providing the regulated service via the Mizuhiki suite.

Footnotes​

  1. Since Ethereum’s transition to Proof of Stake, the words “validator”, “validator node”, and “full node” have been used interchangeably, leading to justifiable confusion amongst developers and policymakers. To help distinguish between a “validator client”, “full node”, and a permissioned system operator on JSC, we have decided to use the term Validator Stack to refer to an infrastructure setup running all three software clients (execution client, consensus client, and validator client), and Validator Client Operator to refer to the title of a permissioned validator client operator on JSC. Those who are not designated Validator Client Operators are not permitted to run validator clients, and may only run execution and consensus clients without permission. Grammatically, we will initially use Validator Stack as a proper noun until it is integrated into the Ethereum lexicon. “Validator client” will continue to refer to the individual software client. We will refrain from using the term “validator” on its own to maintain clarity. Please see Appendix A for further definitions. ↩

  2. Light clients are execution and/or consensus clients that request data from the blockchain as necessary instead of storing local copies, making the hardware requirements for running a light client much lower than a full execution or consensus client. ↩

  3. W3C, Verifiable Credentials Overview, Group Note, Oct. 2024. [Online]. Available: https://www.w3.org/TR/2024/NOTE-vc-overview-20241022/ ↩

  4. W3C, Verifiable Credentials Data Model - Zero Knowledge Proofs, Candidate Recommendation Draft, Oct. 2024. [Online]. Available: https://www.w3.org/TR/vc-data-model-2.0/#zero-knowledge-proofs ↩

  5. Ibid. ↩