From f31955573095a7b76f63b37a25d309dc6dd1c9fc Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Kaan=20Uzdo=C4=9Fan?= Date: Thu, 25 Jun 2026 16:38:24 +0300 Subject: [PATCH] docs(schema): note that version may be a composite multi-binary toolchain string MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The compiled_contracts.version column is not always a single compiler version. Toolchains built from multiple binaries store a composite string identifying the whole toolchain — e.g. ZKsync's zksolc drives a separate solc backend, recorded as 'zksolc:;solc:'. Co-Authored-By: Claude Opus 4.8 --- migrations/20250717103432_database.sql | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/migrations/20250717103432_database.sql b/migrations/20250717103432_database.sql index 9246888..4f0cc4a 100644 --- a/migrations/20250717103432_database.sql +++ b/migrations/20250717103432_database.sql @@ -166,7 +166,11 @@ CREATE TABLE compiled_contracts the syntax ('solidity', 'vyper', 'yul'). there may be future compilers which aren't solc but can still compile solidity, which is why we need to differentiate the two - the version should uniquely identify the compiler + the version should uniquely identify the compiler. for single-binary compilers this is + the plain compiler version (e.g. solc '0.8.26+commit.8a97fa7a', vyper 'v0.3.10'). for + toolchains built from multiple binaries it may be a composite string that identifies the + whole toolchain — e.g. zksync's zksolc drives a separate solc backend, and is recorded as + 'zksolc:;solc:' (e.g. 'zksolc:1.5.10;solc:0.8.26-1.0.2') */ compiler VARCHAR NOT NULL, version VARCHAR NOT NULL,