Add acknacki namespace for Acki Nacki blockchain#182
Add acknacki namespace for Acki Nacki blockchain#182Futurizt wants to merge 2 commits intoChainAgnostic:mainfrom
Conversation
Acki Nacki is a probabilistic proof-of-stake consensus protocol optimized for fast finality with execution parallelization. Runs AVM (Advanced Virtual Machine) supporting TVM and WASM. Published at ACNS 2024 (Springer): doi:10.1007/978-3-031-61486-6_4 Namespace: acknacki Reference: global_id from block header Networks: acknacki:0 — Mainnet acknacki:1 — Shellnet (testnet) Includes: README.md — namespace overview with Springer reference caip2.md — chain ID spec (global_id) caip10.md — account ID spec (DappID.AccountID)
| throughputs via execution parallelization. It achieves higher Byzantine | ||
| fault tolerance than Nakamoto, BFT (including Hotstuff and AptosBFT), | ||
| Solana, and other modern consensus protocols. The protocol reaches | ||
| consensus in two communication steps and has a total number of messages |
There was a problem hiding this comment.
"total number of messages" is a little vague, maybe clarify? total per what?
There was a problem hiding this comment.
Right, ambiguous. Rephrased to "the total number of messages exchanged per consensus round is subquadratic in the number of nodes" — that's what the Springer paper analyzes (per-round communication complexity). Done in 40434a1.
| consensus in two communication steps and has a total number of messages | ||
| that are subquadratic to the number of nodes. | ||
|
|
||
| Acki Nacki runs AVM (Advanced Virtual Machine) supporting both TVM and |
There was a problem hiding this comment.
| Acki Nacki runs AVM (Advanced Virtual Machine) supporting both TVM and | |
| Acki Nacki runs AVM (Advanced Virtual Machine) supporting both Ton Virtual Machine (TVM) and |
To contradistinguish from Tron VM, which uses the same acronym
There was a problem hiding this comment.
Accepted, applied verbatim in 40434a1. Good distinction from Tron VM.
|
|
||
| Acki Nacki is a layer-1 blockchain identified by a `global_id` integer stored | ||
| in every block header. Each network (mainnet, shellnet) has a unique | ||
| `global_id` assigned at genesis. |
There was a problem hiding this comment.
There is no assigning authority — Acki Nacki is permissionless and decentralized. global_id is fixed at genesis and remains constant for the lifetime of the network. The public mainnet (0) and shellnet (1) values are conventionally reserved; anyone bootstrapping a private network selects their own value at genesis. Clarified in the Semantics section in 40434a1.
| Using `global_id` from the block header follows the same pattern as the `tvm` | ||
| namespace (which uses the identical field for Everscale and TON). This provides | ||
| a simple, deterministic, on-chain verifiable identifier that requires no | ||
| external registry. |
There was a problem hiding this comment.
What happens if a new chain is started that "reuses" a chainId already in use? Or if a malicious network starts returning a different chainId over time when queried by the above method? Good to explain this stuff (and link to further reading if "it's complicated") for first-timers, who are the target audience of this document.
There was a problem hiding this comment.
Added a "Verification and Trust Model" subsection in 40434a1 covering both:
(a) protocol-level verification — global_id is embedded in every block header, so a client can cross-check the value against multiple Block Keepers rather than trusting a single GraphQL endpoint. Acki Nacki is permissionless, so no central registry can prevent two unrelated private networks from picking the same global_id; applications needing stronger guarantees should additionally fingerprint the chain (genesis block hash, well-known system contract addresses).
(b) for outside observers requiring cryptographic assurance of the chain history itself, Acki Nacki includes a network-history proof system based on zero-knowledge proofs that lets an external verifier validate the chain witness without trusting any single node. The proof system is currently under test and is planned for activation on mainnet to harden the witness for light clients and cross-chain verifiers.
| forming a 512-bit composite address called `AccountRouting`. | ||
|
|
||
| The DApp ID groups contracts into a logical application. All contracts | ||
| within the same DApp ID share a gas pool (DappConfig) and can transact |
There was a problem hiding this comment.
| within the same DApp ID share a gas pool (DappConfig) and can transact | |
| within the same DApp ID share ONE (1) gas pool (defined in DappConfig) and can transact |
(I'm just guessing here-- if I'm wrong, rephrase to be equally explicit but more accurate!)
There was a problem hiding this comment.
Correct — applied verbatim in 40434a1. Each DApp ID has exactly one DappConfig contract holding the shared SHELL pool that internal calls draw from via gosh.mintshell().
| ### Syntax | ||
|
|
||
| The CAIP-10 account address is the concatenation of the lowercase | ||
| hex-encoded DApp ID and Account ID, separated by a period: |
There was a problem hiding this comment.
I can tell from the examples below that hex-encoded DOESN'T use the 0x prefix common in other blockchains, but you might want to explicitly call that out here for the lazy EVM-familiar skimmer who doesn't check the examples confronted with this ambiguity!
There was a problem hiding this comment.
Added an explicit line in the Syntax section in 40434a1: "Hex encoding is lowercase and does not include the 0x prefix used in EVM-style addresses; both DApp ID and Account ID are exactly 64 hex characters with no separator."
|
|
||
| ## Introduction | ||
|
|
||
| Acki Nacki uses a two-part account addressing scheme. Each account is |
There was a problem hiding this comment.
I'm a little unclear on what an AccountID means by itself. An "Externally owned account", for example, like a metamask on EVM: does that work by itself? Can a P2P transfer with no smart contracts involved work from a bare accountID to a bare accountID, and if so, who pays the gas?
Regardless of whether all this is inherited from "vanilla" TVM, I would spell it out, because as-is it sounds like the only actors on Acki Nacki are what EVM calls "onchain accounts" (controlled/mediated via a deployed contract).
There was a problem hiding this comment.
Good catch — this is a genuine source of confusion for EVM-familiar readers. Added an "Account Model" subsection to caip10.md in 40434a1 spelling out:
- Acki Nacki uses an account-based model where every account is itself a smart contract; there are no EVM-style EOAs.
- A private key is not an actor on its own — it can only sign external messages addressed to an already-deployed contract whose code chooses whether to accept the signature and execute. A "user wallet" is therefore a deployed contract (typically a multisig).
- P2P value transfers always flow contract-to-contract:
- Inside a DApp ID — gas is drawn from the shared
DappConfigpool viagosh.mintshell()(gasless internal txs). - From outside (external message) — the receiving contract pays gas from its own balance. A bare AccountID with no deployed contract is uninitialized; incoming messages either bounce or, when accompanied by a
stateInit, deploy the contract at that address. - Cross-DApp — native VMSHELL is zeroed at the protocol level; ECC tokens (e.g. SHELL) can cross.
- Inside a DApp ID — gas is drawn from the shared
- A bare AccountID is meaningful only as a destination address — it cannot originate a transaction until a contract has been deployed at it.
bumblefudge
left a comment
bumblefudge
left a comment
There was a problem hiding this comment.
Everything other than this comment is a minor stylistic suggestion, but I'd say it's ready to merge if this one blocking comment is addressed.
- Account Model section in caip10.md: every account is a contract; no EOAs; explicit gas-payment rules per scope (intra-DApp gasless, external messages, uninitialized accounts). - caip2.md: Verification and Trust Model section covering BK cross-check, fingerprinting recommendation, and the in-test ZKP network-history proof system planned for mainnet activation. - Governance: clarify decentralized model — bitcoin-style updates, no DAO/foundation/governance body, GOSH as core protocol developer with clickable link. - Apply suggestion blocks: "Ton Virtual Machine (TVM)" disambiguation, "ONE (1) gas pool (defined in DappConfig)" wording. - Clarify "subquadratic messages per consensus round". - Spell out hex encoding is lowercase with no `0x` prefix.
|
Thanks for the thorough review! All seven inline comments addressed in 40434a1:
Ready for another pass. |
3 participants
Summary
Adds the
acknackinamespace for the Acki Nacki blockchain — a probabilistic proof-of-stake consensus protocol optimized for fast finality with execution parallelization, running AVM (Advanced Virtual Machine) supporting TVM and WASM.Peer-reviewed publication: ACNS 2024 (Springer)
Networks
acknacki:0acknacki:1Files
acknacki/README.md— Namespace overview, rationale, governance, Springer referenceacknacki/caip2.md— Chain ID specification (global_idfrom block header)acknacki/caip10.md— Account ID specification (DappID.AccountID, 512-bit composite address)Key differentiators from existing namespaces
DappID.AccountID(not workchain:address)References