fix: replace the EraVM extension page with zksolc docs

content/00.zksync-era/40.tooling/20.hardhat/30.plugins/40.hardhat-zksync-solc.md

@@ -157,10 +157,9 @@ This approach is implemented to provide a caching mechanism, avoiding the risk o
 
 ### ZKsync Era Solidity compiler
 
-Due to [the identified limitations](/zksync-protocol/compiler/toolchain/solidity#limitations)
-of the [upstream Solidity compiler](https://github.com/ethereum/solidity),
-our team has developed [a new edition](%%zk_git_repo_era-solidity%%)
-of the compiler, which effectively addresses and resolves these constraints.
+Due to [several codegen limitations](/zksync-protocol/compiler/specification/evmla-translator)
+of the [upstream Solidity compiler](https://github.com/ethereum/solidity), our team
+had to [fork it](%%zk_git_repo_era-solidity%%) in order to effectively address and resolve these constraints.
 
 For usage of EraVM compiler, `eraVersion` should be added inside `solidity` property in the `hardhat.config.ts` file:
 

content/20.zksync-protocol/50.compiler/10.toolchain/10.index.md

@@ -3,21 +3,15 @@ title: Compiler toolchain overview
 description:
 ---
 
-This section introduces the zkEVM LLVM-based compiler toolchain for smart contract languages with Ethereum Virtual Machine (EVM) support.
+This section introduces an LLVM-based compiler toolchain for Solidity and Vyper.
 The toolchain works on top of existing compilers and requires their output, which typically includes intermediate representations (IRs),
 abstract syntax trees (ASTs), and auxiliary contract metadata and documentation.
 
-::callout{icon="i-heroicons-information-circle" color="blue"}
-At the time of writing, we support Solidity and Vyper.
-::
-
 The toolchain consists of the following:
 
 1. [High-level source code compilers](#high-level-source-code-compilers): `solc` and `vyper`.
 2. [IR compilers, front ends to LLVM](#ir-compilers): `zksolc` and `zkvyper`.
-3. [The LLVM framework](/zksync-protocol/compiler/toolchain/llvm) with a zkEVM back end which emits zkEVM text assembly.
-4. [The assembler](#assembler) which produces the zkEVM bytecode from text assembly.
-5. [Hardhat plugins](#hardhat-plugins) which set up the environment.
+3. [The LLVM framework](/zksync-protocol/compiler/toolchain/llvm) with EraVM and EVM back ends.
 
 ![Compiler Toolchain Visualization](/images/zk-stack/compiler-toolchain.png "Compiler Toolchain")
 
@@ -26,10 +20,10 @@ The toolchain consists of the following:
 High-level source code is processed by third-party compilers. These compilers do the following:
 
 1. Process and validate the high-level source code.
-2. Translate the source code into IR and metadata.
-3. Pass the IR and metadata to our IR compilers via the standard I/O streams.
+2. Translate the source code to artifacts, namely IR and metadata.
+3. Pass the IR and metadata to our IR compilers via stdout using standard JSON I/O.
 
-We are using two high-level source code compilers at the time of writing:
+We are using two high-level source code compilers:
 
 - [solc](https://github.com/ethereum/solc-bin): the official Solidity compiler. For more info, see the latest [Solidity documentation](https://docs.soliditylang.org/en/latest/).
 - [vyper](https://github.com/vyperlang/vyper/releases): the official Vyper compiler. For more info, see the latest [Vyper documentation](https://docs.vyperlang.org/en/latest/index.html).
@@ -43,43 +37,21 @@ to build smart contracts on ZKsync Era.
 
 ## IR Compilers
 
-Our toolchain includes LLVM front ends, written in Rust, that process the output of high-level source code compilers:
+Our toolchain includes LLVM front ends written in Rust. The front ends process the output of high-level source code compilers:
 
-- [zksolc](%%zk_git_repo_zksolc-bin%%) which calls `solc` as a child process. For more info, see the latest [zksolc documentation](/zksync-protocol/compiler/toolchain/solidity).
-- [zkvyper](%%zk_git_repo_zkvyper-bin%%): which calls `vyper` as a child process. For more info, see the latest [zkvyper documentation](/zksync-protocol/compiler/toolchain/vyper).
+- [zksolc](%%zk_git_repo_zksolc-bin%%) which calls `solc` as a child process. For more info, see the latest [zksolc documentation](https://matter-labs.github.io/era-compiler-solidity/latest/).
+- [zkvyper](%%zk_git_repo_zkvyper-bin%%): which calls `vyper` as a child process. For more info, see the latest [zkvyper documentation](https://matter-labs.github.io/era-compiler-vyper/latest/).
 
 These IR compilers perform the following steps:
 
-1. Receive the input, which is usually standard or combined JSON passed by the Hardhat plugin via standard input.
-2. Save the relevant data, modify the input with zkEVM settings, and pass it to the underlying high-level source code compiler
-which is called as a child process.
+1. Receive the input, which is usually standard or combined JSON passed by a tool such as Foundry or Hardhat via standard input.
+2. Save the relevant data, modify the input, and pass it to the underlying high-level source code compiler
+called as a child process.
 3. Receive the IR and metadata from the underlying compiler.
 4. Translate the IR into LLVM IR, resolving dependencies with the help of metadata.
-5. Optimize the LLVM IR with the powerful LLVM framework optimizer and emit zkEVM text assembly.
+5. Optimize the LLVM IR with the powerful LLVM framework optimizer and emit bytecode.
 6. Print the output matching the format of the input method the IR compiler is called with.
 
 Our IR compilers leverage I/O mechanisms which already exist in the high-level source code
-compilers. They may modify the input and output to some extent, add data for features unique to zkEVM,
+compilers. They may modify the input and output to some extent, add data for features unique to ZKsync EraVM,
 and remove unsupported feature artifacts.
-
-## Assembler
-
-The [assembler](%%zk_git_repo_era-zkEVM-assembly%%), which is written in Rust, compiles zkEVM assembly
-to zkEVM bytecode. This tool is not a part of our LLVM back end as it uses several cryptographic libraries which are
-easier to maintain outside of the framework.
-
-## Hardhat Plugins
-
-We recommend using our IR compilers via [their corresponding Hardhat plugins](/zksync-era/tooling/hardhat).
-Add these plugins to the Hardhat's config file to compile new projects or migrate
-existing ones to ZKsync Era. For a lower-level approach, download our compiler binaries via the
-links above and use their CLI interfaces.
-
-### Installing and configuring plugins
-
-Add the plugins below to the Hardhat's config file to compile new projects or migrate
-existing ones to ZKsync Era. For a lower-level approach, download our compiler binaries
-[links above](#ir-compilers) and use their CLI interfaces.
-
-- [hardhat-zksync-solc documentation](/zksync-era/tooling/hardhat/plugins/hardhat-zksync-solc)
-- [hardhat-zksync-vyper documentation](/zksync-era/tooling/hardhat/plugins/hardhat-zksync-vyper)

content/20.zksync-protocol/50.compiler/20.specification/30.system-contracts.md

@@ -116,7 +116,7 @@ For reference, see
 
 ## Auxiliary Heap
 
-Both [zksolc](/zksync-protocol/compiler/toolchain/solidity) and [zkvyper](/zksync-protocol/compiler/toolchain/vyper)
+Both [zksolc](https://matter-labs.github.io/era-compiler-solidity/latest/) and [zkvyper](https://matter-labs.github.io/era-compiler-vyper/latest/)
 compilers for EraVM operate on [the IR level](/zksync-protocol/compiler/toolchain#ir-compilers),
 so they cannot control the heap memory allocator which remains a responsibility of
 [the high-level source code compilers](/zksync-protocol/compiler/toolchain#high-level-source-code-compilers) emitting the IRs.

content/20.zksync-protocol/50.compiler/20.specification/50.evmla-translator.md

@@ -3,23 +3,29 @@ title: EVM Legacy Assembly translator
 description:
 ---
 
-There are two Solidity IRs used in our pipeline: Yul and EVM legacy assembly. The former is used for older versions of
+There are two Solidity IRs used in our pipeline: Yul and EVM legacy assembly. The latter is used for older versions of
 Solidity, more precisely <=0.7.
 
 EVM legacy assembly is very challenging to translate to LLVM IR, since it obfuscates the control flow of the program and
-uses a lot of dynamic jumps. Most of the jumps can be translated to static ones by using a static analysis of EVM assembly,
-but some of jumps are impossible to resolve statically. For example, internal function pointers can be written
-to memory or storage, and then loaded and called. Recursion is another case we have skipped for now, as there is another
-stack frame allocated on every iteration, preventing the static analyzer from resolving the jumps.
+uses a lot of dynamic jumps. Most of the jumps can be translated to static ones by using a form of static analysis,
+but some of them are impossible to resolve this way.
 
-Both issues are being worked on in our fork of the Solidity compiler, where we are changing the codegen to remove the
-dynamic jumps and add the necessary metadata.
+## ZKsync Fork of the Solidity Compiler
 
-Below you can see a minimal example of a Solidity contract and its EVM legacy assembly translated to LLVM IR which is
-eventually compiled to EraVM assembly.
+There were several issues with the existing codegen of the original *solc* compiler:
+
+1. Internal function pointers are written to memory or storage, and then loaded and called dynamically.
+2. With local recursion, there is another stack frame allocated on every iteration.
+3. Some try-catch patterns leave values on the stack, hindering stack analysis.
+
+All the issues have been resolved in [our fork of the Solidity compiler](https://github.com/matter-labs/era-solidity),
+where we have changed the codegen to remove the dynamic jumps and add the necessary metadata.
 
 ## Source Code
 
+In this section you can see a minimal example of a Solidity contract and its EVM legacy assembly translated to LLVM IR which is
+eventually compiled to EraVM bytecode.
+
 ```solidity
 contract Example {
   function main() public pure returns (uint256 result) {

content/20.zksync-protocol/50.compiler/20.specification/60.instructions/10.index.md

@@ -15,7 +15,7 @@ stated explicitly in the description of each instruction.
 ## Addressing modes
 
 EraVM is a register-based virtual machine with different addressing modes.
-It overrides all stack mechanics described in [the original EVM opcodes documentation](https://www.evm.codes/) including
+It overrides all stack mechanics described in [the official documentation of EVM opcodes](https://www.evm.codes/) including
 errors they produce on EVM.
 
 ## Solidity Intermediate Representations (IRs)
@@ -27,22 +27,4 @@ Every instruction is translated via two IRs available in the Solidity compiler u
 
 ## Yul Extensions
 
-At the moment there is no way of adding ZKsync-specific instructions to Yul as long as we use the official Solidity
-compiler, which would produce an error on an unknown instruction.
-
-There are two ways of supporting such instructions: one for Solidity and one for Yul.
-
-### The Solidity Mode
-
-In Solidity we have introduced **call simulations**. They are not actual calls, as they are substituted by our Yul
-translator with the needed instruction, depending on the constant address. This way the Solidity compiler is not
-optimizing them out and is not emitting compilation errors.
-
-The reference of such extensions is coming soon.
-
-### The Yul Mode
-
-The non-call ZKsync-specific instructions are only available in the Yul mode of **zksolc**.
-To have better compatibility, they are implemented as `verbatim` instructions with some predefined keys.
-
-The reference of such extensions is coming soon.
+ZKsync EraVM introduced a set of EraVM-specific instructions. The set is documented at [the official *zksolc* documentation](https://matter-labs.github.io/era-compiler-solidity/latest/).