SOLAREUM
HomeTelegramTwitterWebsiteBuy $SRM
  • ๐Ÿ‘‹Solareum - Layer 1 Whitepaper
  • Solareum (SRM)
    • ๐Ÿ“ƒExecutive Summary
    • ๐Ÿ”ฅSolareumโ€™s Solution
    • โญSolareumโ€™s Value Proposition
    • ๐Ÿ’ซFinal Thoughts
  • About Solareum
    • ๐Ÿ‘ฉโ€๐ŸซWhat is SolareumChain?
    • โž—Mathematical Analysis of Validators
  • Solareum Proof of Generation
    • ๐ŸงŠSolareum Proof of Generation
    • ๐Ÿ›ก๏ธThe BLS12-381 Elliptic Curve for zk-SNARK Proofs
      • FPGA Hardware
  • BLS Key Generation Signature Scheme Security
    • โ™ป๏ธBLS Key Generation
      • Extract
      • Expand
      • IKM to lamport SK
      • parent SK to lamport PK
      • HKDF mod r
      • derive child SK
      • derive master SK
    • ๐Ÿ’ฑPost-quantum security backup upgrade
  • SolareumChain Algorithmic Security
    • ๐Ÿ”SolareumChain Algorithmic Security
    • ๐Ÿ”ฎBLS signature aggregation and Multisig security
      • BLS Signature Aggregation
      • Multisig Security
      • BLS signature aggregation definitions
    • ๐ŸซProving security definition references
      • Gedankenexperiment Setup
      • Gedankenexperiment Signature queries
      • Gedankenexperiment Forgery
      • Security and co-CDH Assumption
    • โœณ๏ธAdversaries and message query theorems
    • ๐Ÿ’ Multi-Input Transactions and Transaction Validation Caching
      • SolareumChain Multi-Input Transactions
      • SolareumChain Transaction Validation Caching
  • SolareumChain ReFi Implementation
    • ๐Ÿ’ฅProof of Hold (PoH)
    • ๐Ÿง‡SolareumChain Inherited NFT Multipliers
  • SolareumChain Architecture and PoG Math
    • โ›“๏ธSolareumChain Architecture and PoG Math
    • ๐Ÿ’ฃSocietal Impact of Blockchain Technology
    • ๐Ÿ’กEnergy Generation Analysis and Correlation
    • ๐Ÿ”‹Energy Correlation Assurance Functions
    • ๐Ÿงฉzk-SNARK Validation
      • Case Study I: Proof of Hold and no Proof of Generation
      • Case Study II: No Proof of Hold and Proof of Generation
      • Case Study III: Proof of Hold and Proof of Generation
    • ๐ŸŽดSolareumChain Address Generation
    • ๐ŸŽฑSolareumChain Genesis Architecture
    • ๐ŸฑDistributed Ledger Technology Energy Sustainability
    • ๐ŸŒ‰SolareumChain Bridge
    • โšกSufficiency of Sub 128-bit Security for Pairing-Friendly Curves on SolareumChain
  • Other iNfo
    • ๐Ÿ“Conclusion
  • Community
    • ๐ŸŒWebsite
    • ๐ŸŒ Telegram
    • โœ–๏ธTwitter
Powered by GitBook
On this page
  1. SolareumChain Architecture and PoG Math

SolareumChain Genesis Architecture

After a genesis block creates the initial SolareumChain block, referred to as B0, which consists of a sole transaction of the first generated Null address executing a Falcon signature for which all SolareumChain native token (SRM) exist as transferred into the next block under which they begin providing the rewards to participants of Proof of Hold (PoH) and Proof of Generation (PoG) as per their respective algorithms. That is, the address 0x000000000000000000 generates a private key through a Falcon signature, for which there is an immediately burned OTP (one-time pad) self-execution that mints all SRM and then destroys access to the null address private key after the B0 โ†’ B1 transaction mapping occurs, as the first block for which Proof of Hold accrues to be paid out at the end of the first block in confirmation leading to the B1 โ†’ B2 transaction mapping and requires Proof of Generation occuring with at least three validators solving the Byzantine General problem for minimum 2/3 consensus to progress to the next block as is ongoing required by SolareumChain. That is, energy generation validators which compute the initial history of

IN : 0x000000000000000000[XSRM]

OUT : 0x000000000000000P oH[XSRM โˆ’ PoH] OUT : 0x000000000000000P oG[XSRM โˆ’ PoG]

where X - PoH - PoG is the amount of potentially bridgeable SRM (ERC-20) tokens from Ethereum Mainnet.

PreviousSolareumChain Address GenerationNextDistributed Ledger Technology Energy Sustainability

Last updated 1 year ago

๐ŸŽฑ