Acki Nacki VM Instructions Business-Level Specification
Prepared by Pruvendo

Purpose
The purpose of the present document is to create business-level specification (highest-level of specification) for the Acki Nacki - specific VM instructions. This document is intended to:
Be thoroughly reviewed by the Customer
Act as a base for the high-level specification
Introduction
Being a TVM-based blockchain, Acki Nacki follows its specification and instruction set. However, some additional instructions are required to support some specific features introduced in Acki Nacki. Such instructions are described in the present document.
Acki Nacki - specific instructions
For all the instructions below the current account is taken from c4 register.
CNVRTSHELLQ
Signature : C727
, where
Brief description: Transforms SHELL into the same amount of VMSHELL (using 1:1 ratio)
Input : - amount of nanotokens to exchange
Behavior:
If the sender has enough balance of SHELL, the required amount of SHELL’s are transformed into VMSHELL
Otherwise, the whole balance of SHELL is transformed into VMSHELL
In any case the counter of special operations is increased
MINTECC
Signature : C726
, where ,
Brief description : mints the required amount of any ECC tokens, can be called by a special contract only
Input : - index of ECC token, - amount of nanotokens to mint
Behavior:
If the contract is not special, NOT_SPECIAL_CONTRACT error happens
If the adding of tokens fails, OVERFLOW error happens
Otherwise:
token balance is increased by the specified amount
counter of special actions is increased
MINTSHELL
Signature : C728
, where
Brief description : mints SHELL tokens, up to the specified amount, using the available credit
Input : n - amount of SHELL nanotokens to be minted
Behavior:
In case of infinite credit, the specified amount of SHELL tokens is minted
Up to the tokens will be minted, but Minted shell value afterwards does not exceed available credit
Minted shell value is increased by the amount of the minted value
In case of success the counter of special actions is increased
All the values must not exceed .
CALCBKREWARD
Signature : C729
, where:
Brief description : calculates and returns validator’s reward by the end of each epoch
Input :
- reputation coefficient
- stake
- total stake at the epoch start
- epoch duration
𝛴- total amount of minted reward tokens
- number of active block keepers
- last calculated reward adjustment
Output : - assigned reward
Behavior: it follows Acki Nacki tokenomics:
CALCMINSTAKE
Signature : C730
, where:
Brief description : calculates a minimal deposit for a validator (in nanotokens)
Input:
- number of needed active blokkeepers (10000)
- number of active blokkeepers
- network duration + ⅓ of the preepoch duration
- total reward amount subtracted by the total slashed amount
Output : - minimally allowed stake
Behavior: it follows Acki Nacki tokenomics
CALCBKREWARDADJ
Signature: C733
All the values must not exceed .
Brief description: adjusts reward engine to be aligned with the theoretical curve.
Input:
- network time
- the previous adjustment factor
- reward period
- average reputation coefficient
- total reward amount
Output : - new adjustment factor
Behavior: it follows Acki Nacki tokenomics
CALCREPCOEF
Signature: C734
All the values must not exceed
Brief description: calculates reputation coefficient based on the reputation time.
Input:
- reputation time
Output : - reputation coefficient
Behavior: it follows Acki Nacki tokenomics
Zero-knowledge instructions
One of the common drawbacks of common blockchain systems is a necessity to use seed phrases for authentication. It’s hard to remember them and other (off-chain) approaches such as OAuth2 that commonly are better in terms or user experience than the former one. The popular solution is to use self-custodial wallets such as Metamask or TON Wallet. Such wallets are often not so transparent as desired and can be vulnerable to attacks (such as the recent Atomic Wallet case).
The provided solution is intended to support popular off-chain authentication systems in blockchain, thus preventing frequent authentication using seed phrases or off-chain wallets, thus combining a high level of security with great user experience.
The solution is based on Zero-knowledge technology and follows the similar solution implemented in Sui blockchain named zkLogin and described here in details, with some important exceptions:
Salt is not defined by the user, but simply works as a second password
Poseidon is used as a hash function
The Ceremony process is completely new
The changes are to be described in a separate document.
VERGRTH16
Verifies the proofs using Groth16 algorithm
Signature : C731
, where:
Brief description : checks zk-Snark proof, returning the logical result
Input:
- slice is public inputs
- proof (in terms of zk-Snark)
- algorithm used, where:
0 - unsecure algorithm
1 - secure algorithm
anything else - test algorithm
Output:
- boolean value that indicates if the verification was correct or not
Behavior is as follows:
and are decoded into corresponding arrays of bytes
proofs then decoded into array of
Proof<Bn254>
structures, using external functionpublic inputs, in their turn, are decoded into array of Fr (where ) using: a. external methods for deserialization to the array of
FieldElementWrapper
b. wrapping by the first elementDepending on , selected the predefined set of verifying keys - unsecure, secure or test
External function with data calculated at steps 2-4 is called to verify the proofs using Groth16 algorithm
POSEIDON
Calculates Poseidon hash.
Signature : C732
, where:
Input:
- JWT header (base64)
- iss (provider’s name) (base64)
- modulus
- ephemeral public key
- maximum epoch
- key index
Output:
- array of public input as a cell
Behavior:
Initially:
is transformed into a string (z-string)
is transformed into a base64 string (h-string)
is transformed into a base64 string (s-string)
is transformed into array of bytes (𝜇-array)
is transformed into a byte array with proper number of bytes, extra bytes are dropped, in case of lack of bytes exception must be raised
is transformed into u64 (m64)
is transformed into a base64 string (i-string)
Then:
is transformed into big number using an external function
is transformed into big number using an external function
is transformed into big number using an external function
is transformed into big number using an external function
is split into two big numbers using external function
is transformed into a string and then, to big number using an external function
is transformed into big number using an external function
Then, an array of public inputs is created using a call of external functions
Finally, the list is serialized into a cell and push into a stack
Last updated