Use new match terminology in all pages (#39)

* Add .vscode to .gitignore

* Update documentation links to reflect new exact match terminology and add @docusaurus/plugin-client-redirects for handling redirect

* Adapt matches description page to new terminology

* Rename match doc file

* Adapt all pages to new match terminology

* Update docs/3. Verification/2. exactMatchVsMatch.md

Co-authored-by: Kaan Uzdoğan <kaanuzdogan@hotmail.com>

* Update .gitignore

* Update match descriptions

---------

Co-authored-by: Kaan Uzdoğan <kaanuzdogan@hotmail.com>

Author: manuelwedler

.gitignore

@@ -18,3 +18,5 @@
 npm-debug.log*
 yarn-debug.log*
 yarn-error.log*
+
+.vscode

blog/finding-auxdatas-in-bytecode/index.mdx

@@ -22,7 +22,7 @@ The runtime bytecode of contracts by default also contain a special field at the
 
 For a visual explanation of everything above, check out [playground.sourcify.dev](https://playground.sourcify.dev/)
 
-Because of its sensitivity, some verifiers leave this field out in verification. In Sourcify’s case, if the recompiled bytecode and the onchain bytecodes match each other exactly (including the auxdata), it’s great. This will give us a [“full match”](https://docs.sourcify.dev/docs/full-vs-partial-match/). If not, we need to find the auxdatas and leave them out when comparing to be able to get at least a "partial match". 
+Because of its sensitivity, some verifiers leave this field out in verification. In Sourcify’s case, if the recompiled bytecode and the onchain bytecodes match each other exactly (including the auxdata), it’s great. This will give us a [“full match”](https://docs.sourcify.dev/docs/exact-match-vs-match/). If not, we need to find the auxdatas and leave them out when comparing to be able to get at least a "partial match". 
 
 However this is not always trivial especially in these cases:
 

blog/human-readable-tx-wg/index.mdx

@@ -28,7 +28,7 @@ As a basic example, our goal is to show something similar to the one on the righ
 
 Nowadays, many wallets can do the basic ABI decoding and show a verified contract link but users still lack a description of the action they are about to take and additional safety information about the contract they are going to interact with.
 
-How we achieve this at Sourcify is through the [NatSpec](https://docs.soliditylang.org/en/latest/natspec-format.html) documentation. If you document your code using NatSpec's `@notice` and `@dev` fields and [fully verify](https://docs.sourcify.dev/docs/full-vs-partial-match/) your contract on Sourcify, the wallet can show the users the description you wrote when calling the function. (details [in this talk at Devcon VI](https://www.youtube.com/watch?v=Ggm82pnalCI) or [this lightning talk](https://www.youtube.com/watch?v=D7gZtHel8Lg)).
+How we achieve this at Sourcify is through the [NatSpec](https://docs.soliditylang.org/en/latest/natspec-format.html) documentation. If you document your code using NatSpec's `@notice` and `@dev` fields and [fully verify](https://docs.sourcify.dev/docs/exact-match-vs-match/) your contract on Sourcify, the wallet can show the users the description you wrote when calling the function. (details [in this talk at Devcon VI](https://www.youtube.com/watch?v=Ggm82pnalCI) or [this lightning talk](https://www.youtube.com/watch?v=D7gZtHel8Lg)).
 
 Over time it became clear to me that even if we convince the majority of developers to document using NatSpec and fully verify on Sourcify, this single route won't solve this wicked problem of **Human-readable Transactions**. The problem is multi-faceted and requires different approaches for different cases. For instance, you can't add NatSpec docs to an already deployed contract, or you can't use [Dynamic Expressions](https://docs.soliditylang.org/en/latest/natspec-format.html#dynamic-expressions) for a commit-reveal transaction (e.g. ENS commit).
 

blog/human-readable-txs-learnings/index.mdx

@@ -61,7 +61,7 @@ This is a MUST. Period. Without verification there's no way to tell what a contr
 
 DO NOT INTERACT WITH CONTRACTS THAT ARE UNVERIFIED
 
-The contract should be verified by a verifier, but ideally it is verified at multiple places. Even better if the verification is a ["perfect/exact match"](/docs/full-vs-partial-match/), this gives you a cryptographic guarantee that what you see is exactly what the contract author deployed, even the comments, whitespaces etc.
+The contract should be verified by a verifier, but ideally it is verified at multiple places. Even better if the verification is a ["perfect/exact match"](/docs/exact-match-vs-match/), this gives you a cryptographic guarantee that what you see is exactly what the contract author deployed, even the comments, whitespaces etc.
 
 Players here: [Blockscout](https://www.blockscout.com), [Etherscan](https://etherscan.io/), [Routescan](https://routescan.io/), [Tenderly](https://tenderly.co/), Sourcify, and the [Verified Alliance](https://verifieralliance.org/) initiative.
 

blog/talk-about-onchain-metadata-hash/index.mdx

@@ -13,7 +13,7 @@ date: 2023-08-13
 
 ## Introduction
 
-Solidity compiler has a feature, not known by everyone, that appends the IPFS hash of the [contract metadata](/docs/metadata/) to the contract bytecode. This hash effectively acts as a _fingerprint_ of the compilation, and when deployed, goes onchain. With that, we can verify the contracts ["perfectly"](/docs/full-vs-partial-match/) and fetch the contract source code from IPFS. One of our
+Solidity compiler has a feature, not known by everyone, that appends the IPFS hash of the [contract metadata](/docs/metadata/) to the contract bytecode. This hash effectively acts as a _fingerprint_ of the compilation, and when deployed, goes onchain. With that, we can verify the contracts ["perfectly"](/docs/exact-match-vs-match/) and fetch the contract source code from IPFS. One of our
 missions at Sourcify is to make this feature more known and used, but [not everyone is a fan of it](https://github.com/ethereum/solidity/issues/1571).
 
 (If you don't fully understand the metadata hash check out [our playground](https://playground.sourcify.dev/) to see it in action.)
@@ -82,7 +82,7 @@ This is because this constructor code part will not be included in the runtime b
 
 ### Verifying with the Runtime Bytecode + Metadata Hash
 
-There's a way around this problem. If you verify a contract with its [metadata hash appended](https://docs.soliditylang.org/en/latest/metadata.html#encoding-of-the-metadata-hash-in-the-bytecode) to the runtime bytecode, you'll get a [full match](http://localhost:3000/docs/full-vs-partial-match/). This means the source code you are looking at is exactly the same as the one that was originally compiled, because if you change anything about the contract (even a whitespace), the metadata hash will change and you will not get a "full match" but a "partial match".
+There's a way around this problem. If you verify a contract with its [metadata hash appended](https://docs.soliditylang.org/en/latest/metadata.html#encoding-of-the-metadata-hash-in-the-bytecode) to the runtime bytecode, you'll get a [full match](http://localhost:3000/docs/exact-match-vs-match/). This means the source code you are looking at is exactly the same as the one that was originally compiled, because if you change anything about the contract (even a whitespace), the metadata hash will change and you will not get a "full match" but a "partial match".
 
 This, I'd argue, is the only foolproof way to verify a contract's source code. This method covers all the cases above and the ones I haven't mentioned or we don't know about yet. By being based on the runtime code, this also removes the need to trust a third party to index the creation bytecode, and instead you can get the bytecode from your own execution client's JSON RPC interface.
 

blog/technical-verification-walkthrough/index.mdx

@@ -479,7 +479,7 @@ This section does not contain any opcodes or executable bytes and therefore inde
 
 However it is not straightforward to find where these sections are in the bytecode. You can read [our blog post](/blog/finding-auxdatas-in-bytecode/) for more technical info how to do this. 
 
-To read more about how this helps with verification [see our docs](/docs/full-vs-partial-match)
+To read more about how this helps with verification [see our docs](/docs/exact-match-vs-match)
 
 Since we replace a `cborAuxdata` with another, this is a `replace` type transformation.
 

docs/20. databaseMigration.md

@@ -25,7 +25,7 @@ We cannot move completely to a database dropping the filesystem because we want
 
 - **RepositoryV1 (deprecated)**: a refined version of the old repository containing contracts stored with new verification and storage strategies.
 - **RepositoryV2**: a filesystem-based repository where sources for each contract are stored in its `sources/` folder, without replicating the contract's original filesystem structure. Instead, it names files using `keccak256(file: string)`.
-- **Database**: a PostgreSQL database based on [the schema of the Alliance Database](https://github.com/verifier-alliance/database-specs) customized to better fit Sourcify. In particular the Alliance Database doesn't allow storing contracts without creation bytecode and it doesn't explicitly support the concept of [full vs partial verification](/docs/full-vs-partial-match).
+- **Database**: a PostgreSQL database based on [the schema of the Alliance Database](https://github.com/verifier-alliance/database-specs) customized to better fit Sourcify. In particular, the Alliance Database doesn't allow storing contracts without creation bytecode.
 
 ## Migration process
 

docs/3. Verification/2 .fullVsPartialMatch.md renamed to docs/3. Verification/2. exactMatchVsMatch.md

@@ -1,7 +1,7 @@
 ---
-id: full-vs-partial-match
-title: Full vs Partial Match
-slug: /full-vs-partial-match
+id: exact-match-vs-match
+title: Exact Match vs Match
+slug: /exact-match-vs-match
 ---
 
 import AvailableOnlyForSolidityAdmonition from "../AvailableOnlyForSolidityAdmonition";
@@ -19,26 +19,28 @@ Different compilation settings i.e. compiler versions, optimization runs result
 
 :::
 
-If the bytecode from recompiling the contract with the given source code files and the metadata correspond to the bytecode of the contract of the given address and chain, it will be a **match**. Sourcify defines two types of matches upon verifying contracts: **full (perfect) matches** and **partial matches**.
+If the bytecode from recompiling the contract with the given source code files and the metadata correspond to the bytecode of the contract of the given address and chain, it will be a **match**. Sourcify defines two types of matches upon verifying contracts: **Exact Matches** and **Matches**.
 
 :::info Info
 
-The match levels will be renamed in Sourcify's API v2:
+The match levels used a different terminology previously:
 
-- Full match will be renamed to **exact match**
-- Partial match will be renamed to **match**
+- Exact Match was called **Full / Perfect Match**
+- Match was called **Partial Match**
 
-This only concerns the naming, and the description of the match levels on this page will still be valid.
+This only concerns the naming. Their semantics are the same as before.
 
 :::
 
-## Full (Perfect) Matches
+## Exact Matches
 
-<AvailableOnlyForSolidityAdmonition description="Vyper contracts don't support full matches because Vyper doesn't include the metadata hash in the bytecode."/>
+<AvailableOnlyForSolidityAdmonition description="Vyper contracts don't support exact matches because Vyper doesn't include the metadata hash in the bytecode."/>
 
-Full matches (sometimes referred as _perfect matches_) refer to the cases when the bytecode of the deployed contract is byte-by-byte the same as compilation output of the given source code files under the compilation settings defined in the [metadata file](/docs/metadata).
+Exact Matches refer to the cases when the bytecode of the deployed contract is byte-by-byte the same (excluding libraries and immutables) as the compilation output of the given source code files under the compilation settings defined in the [Metadata file](/docs/metadata).
 
-This means the contents of the source code files and the compilation settings are exactly the same as when the contract author compiled and deployed the contract. Not even a byte! If you were to add a comment, change a variable or function name, the full match will be broken.
+Most importantly, the fingerprints (metadata hashes) of the onchain code and the recompilation are exactly matching. The Metadata file includes the integrity hash of the source files, such that it is guaranteed that the contents of the source code files are exactly the same as when the contract author compiled and deployed the contract. If you were to add a comment, change a variable or function name, the exact match will be broken.
+
+Note that the addresses of the used [libraries](/docs/libraries) can differ in the bytecode if they were linked after the compilation. Similarly, any [immutables](/docs/immutables) will differ in the recompiled bytecode, as they are only placed into the runtime bytecode during deployment.
 
 How does Sourcify achieve this?
 
@@ -80,18 +82,14 @@ Change a byte in the source code --> Source code hash changes --> Metadata chang
 
 :::
 
-However the only thing that changes in the bytecode when making a non-functional change (add comments, change variable names) is the appended metadata hash field. Which brings us to the partial matches 👇
+However, the only thing that changes in the bytecode when making a non-functional change (add comments, change variable names) is the appended metadata hash field. Which brings us to matches 👇
 
-## Partial Matches
+## Matches
 
-Partial matches refer to cases when the deployed bytecode of the onchain contract match the bytecode resulting from the recompilation with the metadata and the source files **except the metadata hash**.
+Matches refer to cases when the deployed bytecode of the onchain contract match the bytecode resulting from the recompilation with the metadata and the source files **except the metadata hash**.
 
 In other words, the deployed contract and the given source code + metadata _function_ as the same but there are differences in source code comments, variable names, or other metadata fields such as source paths.
 
-This type of match is similar to how Etherscan verifies contracts. Yes, the matching source code in theory functions the same as the deployed contract but the displayed source code can be misleading or the bytecode can contain [excecutable instructions not seen in the source code](https://samczsun.com/hiding-in-plain-sight/).
-
-## Exceptions
+Note that here too, [libraries](/docs/libraries) and [immutables](/docs/immutables) can differ between the onchain bytecode and the recompilation.
 
-### Immutables
-
-### Libraries
+This type of match is similar to how Etherscan verifies contracts. Yes, the matching source code in theory functions the same as the deployed contract but the displayed source code can be misleading or the bytecode can contain [excecutable instructions not seen in the source code](https://samczsun.com/hiding-in-plain-sight/).

docs/3. Verification/4. immutables.md

@@ -8,7 +8,7 @@ slug: /immutables
 
 ## Solidity
 
-While Sourcify can verify **Solidity** contracts containing immutable variables, the process is more intricate than verifying contracts that don't have immutables. First, Sourcify recompiles the contract, which produces the runtime bytecode and the `immutableReferences` object. This object indicates the specific position within the execution bytecode where the immutable variables are located. After obtaining these, the next step is to replace all instances of the immutables in both the runtime and deployed bytecodes with zeros. Finally, a direct comparison is made between the two bytecodes to get a full or a partial match.
+While Sourcify can verify **Solidity** contracts containing immutable variables, the process is more intricate than verifying contracts that don't have immutables. First, Sourcify recompiles the contract, which produces the runtime bytecode and the `immutableReferences` object. This object indicates the specific position within the execution bytecode where the immutable variables are located. After obtaining these, the next step is to replace all instances of the immutables in both the runtime and deployed bytecodes with zeros. Finally, a direct comparison is made between the two bytecodes to get an exact match or a match.
 
 More details on how immutables affect verification below:
 

docs/3. Verification/8. Etherscan.mdx

@@ -11,7 +11,7 @@ import EtherscanInstances from "./etherscanInstancesTable.tsx";
 
 It is possible to import contracts already verified on Etherscan instances.
 
-Usually, if the contract is verified via the "Standard JSON Input", it reveals a "full match" instead of "partial".
+Usually, if the contract is verified via the "Standard JSON Input", it reveals an Exact Match instead of a Match.
 
 [![Etherscan import](./etherscanScreenshot.png)](./etherscanScreenshot.png)