mirror of
https://github.com/lux-apps/papers.git
synced 2026-10-30 18:15:21 +00:00
zeekay
75a04faa36
Resolves high-severity review findings: anachronistic dates aligned to citation floors; arithmetic corrected to match formulas; internal contradictions collapsed to the body-supported value; LP self-references aligned to filenames; liquidity-surface repo paths scrubbed; AI-slop trimmed. PDFs rebuilt separately.
118 lines
6.9 KiB
TeX
118 lines
6.9 KiB
TeX
\section{Conclusion}
|
|
\label{sec:conclusion}
|
|
|
|
Lux Network's custom EVM precompiles provide native-speed cryptographic operations that enable advanced smart contract applications:
|
|
|
|
\begin{enumerate}
|
|
\item Full BLS12-381 support enables on-chain zk-SNARK verification and aggregate signature checking.
|
|
\item Batch secp256k1 verification achieves 40\% gas savings for multi-signature operations.
|
|
\item Post-quantum precompiles (ML-DSA, FALCON) provide quantum-resistant authentication at practical gas costs.
|
|
\item The Warp verification precompile enables constant-gas cross-appchain message validation.
|
|
\item Gas pricing calibrated to execution time within a 1.5x safety factor ensures predictable block execution.
|
|
\end{enumerate}
|
|
|
|
The precompile suite positions Lux Network as the most cryptographically capable EVM platform, supporting both current security needs and future quantum resistance requirements.
|
|
|
|
\subsection{Testing and Formal Verification}
|
|
|
|
Each precompile is validated through a multi-layer testing strategy:
|
|
|
|
\begin{enumerate}
|
|
\item \textbf{Unit tests}: Known-answer tests (KATs) from IETF and NIST specifications for every supported curve and hash function. Coverage includes edge cases: identity elements, points at infinity, maximum-length inputs, and malformed encodings.
|
|
\item \textbf{Differential testing}: Outputs are compared against reference implementations (BLST for BLS12-381, Gnark for BN254, PQClean for ML-DSA/FALCON) across $10^6$ random inputs per operation.
|
|
\item \textbf{Fuzzing}: Continuous fuzzing with AFL++ targeting input parsing, gas calculation, and memory allocation paths. Each precompile undergoes $10^9$ fuzzer iterations before mainnet activation.
|
|
\item \textbf{Gas invariant checking}: Automated verification that gas charged is always $\geq$ measured execution time $\times$ gas-per-nanosecond rate, across all benchmark hardware configurations.
|
|
\end{enumerate}
|
|
|
|
All precompile implementations are open-source and undergo continuous integration testing against the reference test vectors maintained in the \texttt{lux-precompile-tests} repository. New test vectors are added for each EVM upgrade cycle.
|
|
|
|
The testing infrastructure includes a dedicated precompile benchmarking harness that measures execution time on reference hardware (AWS c6g.xlarge ARM instances) and automatically updates gas tables when performance characteristics change due to compiler or library upgrades. The benchmarking results are published in each network upgrade's release notes, providing transparency into gas pricing decisions and enabling third-party auditors to independently verify the gas cost model.
|
|
|
|
\subsection{Precompile Address Allocation}
|
|
|
|
The Lux EVM reserves address range \texttt{0x0200}--\texttt{0x02FF} for network-specific precompiles, avoiding conflicts with the Ethereum-standard range (\texttt{0x01}--\texttt{0x09}) and proposed precompiles (\texttt{0x0A}--\texttt{0x13}). Consistent with Table~\ref{tab:addresses}, the allocation scheme groups precompiles by cryptographic family: \texttt{0x0201}--\texttt{0x020F} for BLS12-381 operations, \texttt{0x0210}--\texttt{0x021F} for BN254, \texttt{0x0220}--\texttt{0x022F} for secp256k1 batch verification, \texttt{0x0230}--\texttt{0x023F} for post-quantum signatures, \texttt{0x0240} for Warp messaging verification, and \texttt{0x0241}--\texttt{0x024F} for hash functions. Per-appchain custom precompiles occupy a separate \texttt{0x0300}--\texttt{0x03FF} range (Section~\ref{sec:upgrade}). This structured allocation simplifies tooling, auditing, and documentation.
|
|
|
|
\bibliographystyle{plain}
|
|
\begin{thebibliography}{30}
|
|
|
|
\bibitem{buterin2014ethereum}
|
|
V.~Buterin, ``Ethereum: A next-generation smart contract and decentralized application platform,'' 2014.
|
|
|
|
\bibitem{eip196}
|
|
C.~Reitwiessner, ``EIP-196: Precompiled contracts for addition and scalar multiplication on the elliptic curve alt\_bn128,'' 2017.
|
|
|
|
\bibitem{eip197}
|
|
C.~Reitwiessner and V.~Buterin, ``EIP-197: Precompiled contracts for optimal ate pairing check on the elliptic curve alt\_bn128,'' 2017.
|
|
|
|
\bibitem{eip2537}
|
|
A.~Vlasov, ``EIP-2537: Precompile for BLS12-381 curve operations,'' 2020.
|
|
|
|
\bibitem{bowe2017bls12381}
|
|
S.~Bowe, ``BLS12-381: New zk-SNARK elliptic curve construction,'' \emph{Zcash Blog}, 2017.
|
|
|
|
\bibitem{nistpqc2024}
|
|
{NIST}, ``Post-quantum cryptography standardization: Selected algorithms,'' 2024.
|
|
|
|
\bibitem{barreto2006subgroup}
|
|
P.~S.~L.~M.~Barreto and M.~Naehrig, ``Pairing-friendly elliptic curves of prime order,'' in \emph{SAC}, 2006.
|
|
|
|
\bibitem{boneh2001bls}
|
|
D.~Boneh, B.~Lynn, and H.~Shacham, ``Short signatures from the Weil pairing,'' in \emph{ASIACRYPT}, 2001.
|
|
|
|
\bibitem{boneh2018compact}
|
|
D.~Boneh, M.~Drijvers, and G.~Neven, ``Compact multi-signatures for smaller blockchains,'' in \emph{ASIACRYPT}, 2018.
|
|
|
|
\bibitem{groth2016size}
|
|
J.~Groth, ``On the size of pairing-based non-interactive arguments,'' in \emph{EUROCRYPT}, 2016.
|
|
|
|
\bibitem{bellare1998batch}
|
|
M.~Bellare, J.~A.~Garay, and T.~Rabin, ``Fast batch verification for modular exponentiation and digital signatures,'' in \emph{EUROCRYPT}, 1998.
|
|
|
|
\bibitem{schwartz1980fast}
|
|
J.~T.~Schwartz, ``Fast probabilistic algorithms for verification of polynomial identities,'' \emph{JACM}, 1980.
|
|
|
|
\bibitem{chen2021pqblockchain}
|
|
L.~Chen et al., ``Post-quantum cryptography for blockchain: A survey,'' \emph{ACM Computing Surveys}, 2021.
|
|
|
|
\bibitem{dilithium2022}
|
|
L.~Ducas et al., ``ML-DSA (FIPS 204, formerly CRYSTALS-Dilithium): Algorithm specifications and supporting documentation,'' \emph{NIST PQC Round 3}, 2022.
|
|
|
|
\bibitem{falcon2020}
|
|
T.~Prest et al., ``FALCON: Fast-Fourier lattice-based compact signatures over NTRU,'' \emph{NIST PQC Round 3}, 2020.
|
|
|
|
\bibitem{pippenger1980evaluation}
|
|
N.~Pippenger, ``On the evaluation of powers and related problems,'' in \emph{FOCS}, 1976.
|
|
|
|
\bibitem{nakamoto2008bitcoin}
|
|
S.~Nakamoto, ``Bitcoin: A peer-to-peer electronic cash system,'' 2008.
|
|
|
|
\bibitem{wood2014ethereum}
|
|
G.~Wood, ``Ethereum: A secure decentralised generalised transaction ledger,'' \emph{Ethereum Yellow Paper}, 2014.
|
|
|
|
\bibitem{galbraith2012}
|
|
S.~D.~Galbraith, ``Mathematics of public key cryptography,'' Cambridge University Press, 2012.
|
|
|
|
\bibitem{shor1994}
|
|
P.~W.~Shor, ``Algorithms for quantum computation: Discrete logarithms and factoring,'' in \emph{FOCS}, 1994.
|
|
|
|
\bibitem{mosca2018}
|
|
M.~Mosca, ``Cybersecurity in an era with quantum computers,'' \emph{IEEE Security \& Privacy}, 2018.
|
|
|
|
\bibitem{bernstein2017pq}
|
|
D.~J.~Bernstein and T.~Lange, ``Post-quantum cryptography,'' \emph{Nature}, vol.~549, pp.~188--194, 2017.
|
|
|
|
\bibitem{rfc9380}
|
|
A.~Faz-Hernandez et al., ``Hashing to elliptic curves,'' \emph{RFC 9380}, 2023.
|
|
|
|
\bibitem{costello2012pairings}
|
|
C.~Costello, T.~Lange, and M.~Naehrig, ``Faster pairing computations on curves with high-degree twists,'' in \emph{PKC}, 2010.
|
|
|
|
\bibitem{bls_ietf}
|
|
S.~Boneh et al., ``BLS signature scheme,'' \emph{IETF Internet-Draft}, 2022.
|
|
|
|
\bibitem{lyubashevsky2012lattice}
|
|
V.~Lyubashevsky, ``Lattice signatures without trapdoors,'' in \emph{EUROCRYPT}, 2012.
|
|
|
|
\end{thebibliography}
|
|
|