Scappi

Authentication in decentralized systems is one of the most challenging solutions to solve.

Why? Weak identification systems in place. Single point of authentication - adding more risks to points of failures.

Solution:

Inherence-based (something the user is/does), state-changing authentication scheme: SCAS.

SCAS assigns some unique state-changing capability to each user for them to authenticate themselves to the blockchain system.

Scappi goal: Authenticate a user uniquely using only decentralized resources and no intermediary secret.

Scappi is a third kind of authentication scheme: Inherence-based (something the user does), by leveraging the interactions the blockchain system enable external users to do to change its state. That is: an authentication scheme that assigns some unique state-changing capability to each user allows them to authenticate themselves to the blockchain system.

State-changing authentication (SCA) schemes = SCAS.

Scappi advantages with respect of traditional blockchain-authentication schemes:

Parallel authentication: You can authenticate to multiple chains with the same external action from the user, resulting in a parallel cross-chain authentication and a better user experience (no need for approval processes on multiple chains).

Blockchain-two-factor authentication: SCAS are more secure than private keys (single point of failure) when operations ask for the state of multiple chains to be changed: A blockchain-two-factor authentication process.

Anti-theft mechanisms: Anti-spoofing mechanisms are possible by systematically perturbing the state-changing operation that the spoofer is attempting, increasing overall security and robustness of the authentication process.

Flexible: SCAS can be based on many stimuli: Transaction capabilities of a combination of user-owned wallets (TIWs). Function-calling capabilities on smart contract controlled by NFT ownership. General on-chain data operations.

Power in being General: Popular systems and structures such as social-recovery wallets, multi-signature schemes, and blockchain-events listeners are generalized by SCAS in the sense that SCAS can simulate any of them and build on top of them

Use cases:

Additionaly to simulating any use case of the previously mentioned schemes/systems, SCAS can be used specifically to:

100% decentralized protection and retrieval of some secret, such a private keys. Prove that the owner of two (or more) specific wallets on different chains belong to the same person. Prove to a new chain that you have some presence history on some blockchain. Authenticate yourself to some service on the blockchain system in a trust-less way.

Goal: Authenticate a user uniquely using only decentralized resources and no intermediary secret.

This means:

Input: Some action from the user, mapped into a set of states only they should be able to change from a given (but arbitrary) starting state. The state in a EVM-based chain can be described as a vector of accounts objects plus some EVM stack. For our purposes, our total state space will be the transaction history of each account and, for a given user, u, we define their unique associated state subspace, S_u, es the transaction history of some selected wallets. Output: Result<Bool> that can take the following values: Ok(True), Ok(False), Error.

Users = requesters: Initiate authentication requests to the smart contract. Specifically: Sends request (hash(requester_address)) to the request queue. Performs state-changing action: Takes the initial state s_0, and changes it into some state from S_u, achievable from s_0. Specifically: sends transactions from the TIWs (dummy wallets we pretend the user can influence). Can receive message from the validators (the SCAS shards). Can reconstruct the SCAS shards into the original SCA token (SCAT). Specifically: reconstruct_scat

Validators: Listens to smart contract request queue. Specifically: Have a method called subscribe_to_sca_contract(Address: String) -> Bool (from JS) that returns confirmation of the subscription success. Reacts to requests by accepting it (in case they have some SCAS shard for the respective user) or rejecting it otherwise. Specifically: Have a method called applicable_request(request: String) -> { applicable: Bool, scas_shard: String } Checks changes of state on the blockchain after some time, T, post-acceptance of a request. Specifically: A method called check_state(TIWs: Vec<Address>, request_id: String) Sends requester their SCAS shard. Specifically: send_scas_shard Mediator structure = Smart contract: Contains request_queue: Vec<String> Contains available_validators: Vec<String> Manages payment in filecoin to the validators.

Setup stage:

Agents running validator nodes should exist in the network. All validator nodes subscribe to the smart contract by giving their given id to publicly announce on a available_validators array that they are subscribed. User sign-up stage

User wants to authenticate to the blockchain. They need to first “sign-up”. This requires to pay upfront for the time-window selected for the authentication to remain valid. a ScasId is produced for the user by the create_ScadId function (random number).

The ScasID is split by shamir_sharing(n: Int, ScasID: String) -> Vec<String> function into n pieces for n validators. We call these shards SCAS shards.

User randomly selects n validators from the available_validators array. User sends every selected validator one SCAS shard and each validator updates their secret-consensus table, consensus_table. The smart contract here records the validators that accepted and holds the payed for later payment of the validators (after they proof-of-spacetime).

Validator signals success on the receiving end (by proof-of-replication). User authentication stage User sends a request (hash(requester_address)) with the send_request() -> String function, to the request_queue on the smart contract with a request_id.

Every validator checks if the request corresponds to some SCAS shard they have by the applicable_request(request: String) -> { applicable: Bool, scas_shard: String } function. Every validator that checks positively, sends a challenge of state change with their method generate_challenge() -> Int. this challenge is stored on each validator’s state, associated with the request_id. Each validator with a challenge sends them to the requester. A time counter begins to run for T time-units (either real-world time units or blockchain epochs). The requester changes the state of the blockchain. After T time-units, each validator checks the validity of the state-change. If checked positively, each validator send the requester their SCAS shard. The user reconstructs the SCAT from the SCAS shards. This concludes the authentication.