35. Future Roadmap

The Quorlin Smart Contract Language and the Kortana Virtual Machine (KVM) are engineered with a modular, forward-compatible architecture. The language design emphasizes human readability ("looks like Java and reads like English") while compiling to a deterministic, RISC-inspired bytecode executed by the KVM.

This roadmap details the planned technical evolution of Quorlin and the KVM. Each milestone directly expands upon the underlying C++ toolchain—including the multi-pass compiler (quorlin/compiler.cpp), the semantic analyzer (quorlin/sema.cpp), the ABI generator (quorlin/abi.cpp), and the KVM runtime interpreter (kvm/interpreter.cpp).

1. Dynamic Return Types in External Calls

The Current Limitation

In the current release, Quorlin standard interfaces (such as IERC20 in quorlin/standard.cpp) omit optional metadata functions like name() and symbol(). As documented in quorlin/standard.cpp:

"name, symbol and decimals are optional in the standard and omitted here: a caller that needs them is displaying a token rather than moving one, and text returned from an external call is not something this language can receive."

Currently, the semantic analyzer (Analyzer::analyze) and the code generator (CodeGenerator) support cross-contract standard calls returning scalar types (Type::U256, Type::Bool, Type::Address). Variable-length types like Type::Text (text in Quorlin) are bounded by fixed limits (such as kMaxTextBytes) during local evaluation, but cannot yet be dynamically decoded from raw call data returned by remote contracts.

Technical Target

To remove this boundary, the roadmap introduces dynamic decoding for remote text and dynamic byte arrays.

Decoder Buffer Pipeline: Update kvm/interpreter.cpp to handle variable-length tail offsets during cross-contract return decoding.
Semantic Unpacking: Extend quorlin/sema.cpp to validate and type-check external calls whose target signature resolves to Type::Text.
Standard Library Expansion: Update built-in interfaces in quorlin/standard.cpp to include ERC-20 metadata and complete EIP compliance.

// Future ERC-20 interface standard with dynamic text return support
interface IERC20Extended {
    reads number totalSupply()
    reads number balanceOf(address owner)
    reads text name()
    reads text symbol()
}

contract TokenViewer {
    reads text fetchName(address tokenAddress) {
        IERC20Extended token = IERC20Extended(tokenAddress);
        // Returning dynamic text from an external contract call
        return token.name();
    }
}

2. KVM Bytecode Specification & Module Versioning (v2+)

The KVM binary module format (kvm/module.cpp) utilizes a strict, big-endian 18-byte fixed header layout followed by explicit constant tables and bytecode instructions:

offset  size  field
0       4     magic "KVM\0"
4       2     version            (big endian)
6       4     constant count     (big endian)
10      4     instruction count  (big endian)
14      4     entry point        (big endian instruction index)
18      ...   constants (32 bytes each, big endian)
...     ...   code (4 bytes per 32-bit fixed instruction)

In the initial module format (version 0x0001), instruction offsets and constant tables are constrained by fixed 32-bit headers. The roadmap outlines KVM Version 2 (0x0002), introducing the following non-breaking binary features:

Dynamic Constant Table Slotting: Expanding constant allocations beyond fixed 32-byte static words to support zero-copy slice references for large string literals (kMaxTextBytes).
Extended Jump Offsets: Supporting explicit 24-bit immediate jump targets (kImm24Mask) across large contract modules without requiring intermediate jump-table fixups.
Module Verification Hooks: Enhancing kvm::Module::deserialize with upfront static path validation to reject invalid instruction streams prior to execution.

+-----------------------------------------------------------------------+
|                       KVM Binary Module (v2)                          |
+-----------------------------------------------------------------------+
| Magic: "KVM\0" (4B) | Version: 0x0002 (2B) | Const Count: uint32 (4B)  |
+-----------------------------------------------------------------------+
| Inst Count: uint32 (4B)                  | Entry Point: uint32 (4B)   |
+-----------------------------------------------------------------------+
| Constant Pool (Variable/32B Big-Endian Entries)                       |
+-----------------------------------------------------------------------+
| Code Section (Fixed 32-bit Instructions: Opcode | Rd | Rs1 | Rs2/Imm)  |
+-----------------------------------------------------------------------+

3. Advanced Lexical, Type, and Record Capabilities

Quorlin maps user-facing English-like types to internal compiler primitives:

Quorlin Type (`type_name`)	ABI Type (`abi_type_name`)	Internal Enum (`Type`)
`number`	`uint256`	`Type::U256`
`truth`	`bool`	`Type::Bool`
`address`	`address`	`Type::Address`
`text`	`string`	`Type::Text`
`nothing`	`void`	`Type::Void`

Field List Diagnostics & Record Evolution

When field resolution fails in records, quorlin/sema.cpp constructs detailed diagnostics (e.g., listing fields like `seller`, `price` and `active`). The roadmap expands record and structural mapping features:

Nested Record Inlining: Allowing complex record structures containing sub-records and dynamic maps.
Immutable Record Fields: Introducing compile-time immutability checking for record attributes assigned in constructors.
Enhanced Diagnostic Formatting: Expanding diagnostic bags in quorlin/compiler.cpp to offer auto-correction hints when identifiers fail semantic checks.

record Vault {
    address owner;
    number collateral;
    truth active;
}

contract VaultManager {
    map<address, Vault> userVaults;

    event VaultCreated(address indexed user, number collateral);

    writes truth openVault(number initialDeposit) {
        require initialDeposit > 0, "deposit must be positive";
        
        Vault newVault = Vault{
            owner: caller,
            collateral: initialDeposit,
            active: yes
        };

        userVaults[caller] = newVault;
        emit VaultCreated(caller, initialDeposit);
        return yes;
    }
}

4. KVM Instruction Set Architecture (ISA) & Gas Optimization

RISC-Form Encoding Upgrades

The KVM ISA (kvm/isa.cpp) encodes instructions in standard fixed-width 32-bit formats:

R-Form: [ Opcode (8b) | Rd (5b) | Rs1 (5b) | Rs2 (5b) | Funct (9b) ]
I-Form: [ Opcode (8b) | Rd (5b) | Rs1 (5b) | Imm (14b) ]
J-Form: [ Opcode (8b) | Imm (24b) ]

// From kvm/isa.cpp
constexpr uint32_t kOpcodeShift = 24;
constexpr uint32_t kRdShift     = 19;
constexpr uint32_t kRs1Shift    = 14;
constexpr uint32_t kRs2Shift    = 9;

Gas Schedule Fine-Tuning

The gas metering framework (kvm/gas.cpp) charges deterministic operational tiers:

kGasZero (0 gas): Free operations like Stop, Return, Revert.
kGasVeryLow (3 gas): Simple register ALU and memory loads (Add, Sub, And, Or, MLoad, MStore).
kGasLow (5 gas): Multiplication and division primitives (Mul, Div, Mod).

+-----------------------------------------------------------------+
|                    Gas Execution Categories                     |
+-----------------------------------------------------------------+
| Tier          | Cost     | Associated Opcodes                   |
+---------------+----------+--------------------------------------+
| Free          | 0 Gas    | Stop, Return, Revert, Invalid        |
| Very Low      | 3 Gas    | Add, Sub, Eq, Lt, Gt, MLoad, MStore  |
| Low           | 5 Gas    | Mul, Div, Mod, SDiv, SMod            |
| Mid / Complex | Variable | Keccak256, Blake3, State Reads/Writes|
+-----------------------------------------------------------------+

Planned ISA Optimizations

Vectorized Cryptographic Opcodes: Optimizing cryptographic primitives in kvm/interpreter.cpp (keccak256, blake3) to process memory regions directly with register-provided length pointers.
Pipelined Register Allocation: Improving register reutilization inside CodeGenerator::emit (quorlin/codegen.cpp) to reduce register spilling in arithmetic loops.
Unified Storage Pricing: Streamlining storage modifications in kvm/state_host.cpp. When updating key-value pairs (StateHost::set_storage), gas costs are dynamically adjusted based on whether the operation updates an existing slot or initializes a new one.

5. State Trie Integration & Ethereum Interoperability

Unified State Host Engine

The KVM relies on StateHost (kvm/state_host.cpp) to interface directly with the underlying blockchain state trie (kortana::state::WorldState). Storage lookup calls route through a single unified pathway:

Result<uint256_t> StateHost::get_storage(const Address& address, const uint256_t& key) const {
    // Satisfies the unified state trie requirement:
    return world_.get_storage(address, key);
}

ABI Alignment with Ethereum Standards

Although Quorlin uses English-like primitive terms (number, truth, text), the ABI generator (quorlin/abi.cpp) outputs Ethereum-compatible JSON targets. As specified in quorlin/parser.cpp:

"The ABI is Ethereum's, so these are Ethereum's names: uint256, not number and not u256... every function selector matches standard Ethereum tooling."

[
  {
    "type": "constructor",
    "inputs": []
  },
  {
    "name": "transfer",
    "type": "function",
    "stateMutability": "nonpayable",
    "inputs": [
      {
        "name": "recipient",
        "type": "address",
        "internalType": "address"
      },
      {
        "name": "amount",
        "type": "uint256",
        "internalType": "number"
      }
    ],
    "outputs": [
      {
        "name": "",
        "type": "bool",
        "internalType": "truth"
      }
    ]
  }
]

Cross-VM Architecture Targets

The final milestone of the roadmap enhances seamless interoperability between Quorlin and standard Solidity contracts co-existing on the Kortana Blockchain:

Shared Storage Tries: Quorlin contracts (.ql) and Ethereum Virtual Machine (EVM/KEVM) contracts execute side-by-side over the identical trie structure managed by StateHost.
Unified Call Dispatcher: Calls initiated via StateHost::call dispatch seamlessly across both KVM modules and standard EVM bytecodes.
Cross-Language Events: Standardized indexing rules in quorlin/abi.cpp (parameter_json with indexed flags) ensure off-chain indexers process Quorlin logs and Solidity logs identically.

+-------------------------------------------------------------------------+
|                       Kortana Unified State Engine                      |
+-------------------------------------------------------------------------+
|                         WorldState Trie Storage                         |
+-------------------------------------------------------------------------+
                                    |
                    +---------------+---------------+
                    |                               |
        +-----------------------+       +-----------------------+
        |  KVM StateHost Bridge |       | KEVM StateHost Bridge |
        +-----------------------+       +-----------------------+
                    |                               |
        +-----------------------+       +-----------------------+
        |   Quorlin Contracts   |       |  Solidity Contracts   |
        |        (.ql)          |       |        (.sol)         |
        +-----------------------+       +-----------------------+

Through this architecture, Quorlin delivers an expressive language model without sacrificing EVM compatibility or execution efficiency.