Financie Token
  • Financie Token - FNCT
  • Disclaimer
  • What is FiNANCiE
  • Challenges and Solutions of Creator Economy
    • Background
      • East India Company Changed the Way to Obtain Challenge Funds
      • From the “Company” to the “Individual”
      • The Relationship between “Fan” and “Creator”
    • Challenges of Creator Economy
      • Profits Are Concentrated on Huge Platforms and a Handful of Creators
      • No Mechanism for Giving Back to the Fans
    • Solution Offered by FiNANCiE
      • Features of FiNANCiE (Crowdfunding 2.0)
      • FiNANCiE and FNCT
  • About the Project
    • Why Blockchain is the Appropriate Technology
      • Proof of the Token’s Authenticity
      • A Safe Secondary Distribution
      • An Open Interchangeability with the Broader Economy
    • FiNANCiE Lightning and Past Achievements
    • Expansion of Blockchain Market and Use Case
      • The Expanding Blockchain Market
      • Expanding Use Case: Fan Tokens
    • Expanding the Token Economy Through FNCT
  • Project Overview
    • FiNANCiE(Crowdfunding 2.0)
      • Issuance of CT (Funding / Initial Sale)
      • Applications of CT
      • CT Marketplace (Secondary Distribution)
    • FNCT(Financie Token)
      • Participation in Governance
  • Technical Specifications
    • CT
    • FiNANCiE Lightning
      • IPFS Log Format
      • Anonymization and Zero-Knowledge Proof
      • Record of History Hash Value
    • FNCT
      • Implementation / Distribution Platform and Token Standards
      • Means of Distributing Community Rewards
    • Token Ecosystem of FNCT
      • FNCT Staking
      • Incentive Rewards
        • Validation Reward
        • Community Token Holding
      • Utility
        • Governance
        • Exchange with CT (Consumption)
        • Grade Benefits
        • Community Donation
      • Buyback & burn
      • Improvement Continues
  • FNCT Token Sale and Usage Plan
    • Token Sale (IEO) Overview
    • Distribution of FNCT Holders
      • Initial Distribution of FNCT
      • Uses of Procured Funds
      • Lock up for Team
      • Release of Allocation and Market Distribution Volume
  • Roadmap
  • Team
  • Community
Powered by GitBook
On this page
  1. Technical Specifications
  2. FiNANCiE Lightning

Anonymization and Zero-Knowledge Proof

PreviousIPFS Log FormatNextRecord of History Hash Value

Last updated 2 years ago

All transaction information is made public while meeting the following requirements to protect privacy (anonymizing the trader) at the same time.

Requirement

  • For the trader himself/herself to display the fact that the transaction had taken place without a third party and also without disclosing the trader’s own private key

  • Inability to determine the trader from transaction history or from the combination of transaction history

  • Low cost

Should the original ID of the trader who has completed the transaction is recorded, it will become possible to determine every past transaction conducted by this certain trader. Therefore, the focus was to find ways to provide the transaction history of a certain trader which history can be traceable to this certain trader but without recording the trader’s ID. Now, this is a potential privacy issue regarding Ethereum’s wallet address and its transaction history. But since the technology already offers a solution, it has advantages other than operational speed when compared to an all-on-chain implementation.

To meet the above requirements, a zero-knowledge proof model is adopted.

The following is an overview of the model.

  1. From the payload of each transaction, a signature key (private key) is generated by using a different private key for each user. This key will be generated for each transaction.

  2. A signature key is used to sign the transaction, which is then published with the content of the transaction.

  3. If you want to prove to a third party that you are the trader of this transaction, present the transaction log published with the signature key of the corresponding transaction. The verifier confirms that the signature key received is identical to the signature.

Displayed in the diagram below.