Merge pull request #2 from kroma-network/chore/fix-lint-check

chore: fix lint check

specs/SUMMARY.md

@@ -1,7 +1,7 @@
 <!-- DOCTOC SKIP -->
 
 # Summary
- 
+
 - [Root](./root.md)
 - [Introduction](./introduction.md)
 - [Kroma Protocol](./protocol/overview.md)
@@ -23,4 +23,4 @@
 - [Fault Proof]()
   - [Challenge](./fault-proof/challenge.md)
   - [zkEVM Prover](./fault-proof/zkevm-prover.md)
-- [Glossary](./glossary.md)
+- [Glossary](./glossary.md)

specs/glossary.md

@@ -26,7 +26,6 @@
   - [Priority Gas Auction](#priority-gas-auction)
 - [Sequencing](#sequencing)
   - [Sequencer](#sequencer)
-  - [Maximal Extractable Value](#maximal-extractable-value)
   - [Sequencing Window](#sequencing-window)
   - [Sequencing Epoch](#sequencing-epoch)
   - [L1 Origin](#l1-origin)
@@ -114,8 +113,8 @@ refers to the Ethereum blockchain.
 
 Can refer to an [L1] block, or to an [L2] block, which are structured similarly.
 
-A block is a sequential list of transactions, along with a couple of properties stored in the *header* of the block. A
-description of these properties can be found in code comments [here][nano-header], or in the [Ethereum yellow paper
+A block is a sequential list of transactions, along with a couple of properties stored in the *header* of the block.
+A description of these properties can be found in code comments [here][nano-header], or in the [Ethereum yellow paper
 (pdf)][yellow], section 4.3.
 
 It is useful to distinguish between input block properties, which are known before executing the transactions in the
@@ -196,8 +195,8 @@ proof to be constructed for any key-value mapping encoded in the tree. Such a pr
 verified against the Merkle root.
 
 Whereas [L1] uses [MPT][mpt] to represent state, [L2] uses ZKT. This is because ZKT enables faster proof
-generation by avoiding [Keccak][keccak] and [RLP encoding][RLP format]. To accomplish this, ZKT uses poseidon hash to calculate
-the path and concatenates leaf values in bytes.
+generation by avoiding [Keccak][keccak] and [RLP encoding][RLP format].
+To accomplish this, ZKT uses poseidon hash to calculate the path and concatenates leaf values in bytes.
 
 ## Chain Re-Organization
 
@@ -773,7 +772,8 @@ The unsafe L2 head is the highest [unsafe L2 block][unsafe-l2-block] that a [rol
 
 [consolidation]: glossary.md#unsafe-block-consolidation
 
-Unsafe block consolidation is the process through which the [rollup node][rollup-node] attempts to move the [safe-L2-head] a block forward, so that the oldest [unsafe L2 block][unsafe-l2-block] becomes the new safe L2 head.
+Unsafe block consolidation is the process through which the [rollup node][rollup-node] attempts to move the
+[safe-L2-head] a block forward, so that the oldest [unsafe L2 block][unsafe-l2-block] becomes the new safe L2 head.
 
 In order to perform consolidation, the node verifies that the [payload attributes][payload-attr] derived from the L1
 chain match the oldest unsafe L2 block exactly.
@@ -786,7 +786,7 @@ See the [Engine Queue section][engine-queue] of the L2 chain derivatiaon spec fo
 
 [finalized-l2-head]: glossary.md#finalized-l2-head
 
-The finalized L2 head is the highest L2 block that can be derived from _[finalized][finality]_ L1 blocks — i.e. L1
+The finalized L2 head is the highest L2 block that can be derived from *[finalized][finality]* L1 blocks — i.e. L1
 blocks older than two L1 epochs (64 L1 [time slots][time-slot]).
 
 [finality]: https://hackmd.io/@prysmaticlabs/finality

specs/meta/devnet.md

@@ -58,7 +58,7 @@ The batch submitter uses the account below to submit batches to L1:
 We added a debugging configuration called 'Attach to devnet process' to .vscode/launch.json. Therefore, on Linux, you
 can use VS Code to attach to the devnet process and perform debugging as shown in the figure below.
 
-![vscode_debug](../assets/vscode_debug.png)
+![vscode_debug](../static/assets/vscode_debug.png)
 
 You might need to disable linux ptrace protection.
 

specs/meta/linting.md

@@ -51,7 +51,7 @@ To update the TOC, we run [doctoc], installed through the dev-dependencies in `p
 
 See
 
-- [golangci-lint docs](https://golangci-lint.run/usage/install/#local-installation)
+- [golangci-lint docs](https://golangci-lint.run/welcome/install/#local-installation)
 - [golangci-lint github](https://github.com/golangci/golangci-lint)
 - [github action github](https://github.com/golangci/golangci-lint-action)
 

specs/meta/markdown-style.md

@@ -44,7 +44,7 @@ In general:
 - Example: [Rollup Node Specification source][rollup-node]
 
 [glossary]: ../glossary.md
-[rollup-node]: ../rollup-node.md
+[rollup-node]: ../protocol/rollup-node.md
 
 ## Internal (In-File) Links
 

specs/meta/validator-deposit.md

@@ -12,19 +12,20 @@
 
 <!-- END doctoc generated TOC please keep comment here to allow auto update -->
 
-We want the [validator](../../kroma-validator/) role to be decentralized. Like how the PoS mechanism works, to
-achieve this, a validator needs to bond ETH at every [output
-submission](../validator.md#submitting-l2-output-commitments). When submitting an output, the amount of bond
-specified by the validator is automatically bonded from [the ETH the validator has deposited into the
-`ValidatorPool`](#deposit-into-validatorpool). The bonded ETH is automatically unbonded when the submitted output is
-finalized. The finalization of the output is checked when the next outputs are submitted, or if the finalization period
-of the submitted output has passed, you can directly [trigger unbond by using the `unbond` command](
-  #try-unbond-in-validatorpool). For more details about submitting an output as a validator, see
-[here](../validator.md).
+We want the [validator](https://github.com/kroma-network/kroma/tree/main/kroma-validator)
+role to be decentralized. Like how the PoS mechanism works, to achieve this, a validator needs to bond ETH at every
+[output submission](../protocol/validator.md#submitting-l2-output-commitments).
+When submitting an output, the amount of bond specified by the validator is automatically bonded from
+[the ETH the validator has deposited into the `ValidatorPool`](#deposit-into-validatorpool).
+The bonded ETH is automatically unbonded when the submitted output is finalized.
+The finalization of the output is checked when the next outputs are submitted, or if the finalization period
+of the submitted output has passed, you can directly
+[trigger unbond by using the `unbond` command](#try-unbond-in-validatorpool).
+For more details about submitting an output as a validator, see [here](../protocol/validator.md).
 
 This guide teaches you how to deposit, withdraw, or try to unbond in `ValidatorPool` via CLI. You can find the proxy
-address of `ValidatorPool` on Sepolia [here](../../packages/contracts/deployments/sepolia/ValidatorPoolProxy.json),
-on Mainnet TBD.
+address of `ValidatorPool` on Mainnet
+[here](https://github.com/kroma-network/kroma/blob/main/packages/contracts/deployments/mainnet/ValidatorPoolProxy.json).
 
 ## Deposit into `ValidatorPool`
 

specs/protocol/differences-from-optimism.md

@@ -2,11 +2,11 @@
 
 <!-- All glossary references in this file. -->
 
-[g-l2-output-root]: glossary.md#l2-output-root
-[g-mpt]: glossary.md#merkle-patricia-trie
-[g-zktrie]: glossary.md#zk-trie
-[g-zk-fault-proof]: glossary.md#zk-fault-proof
-[g-system-config]: glossary.md#system-configuration
+[g-l2-output-root]: ../glossary.md#l2-output-root
+[g-mpt]: ../glossary.md#merkle-patricia-trie
+[g-zktrie]: ../glossary.md#zk-trie
+[g-zk-fault-proof]: ../glossary.md#zk-fault-proof
+[g-system-config]: ../glossary.md#system-configuration
 [g-validation-rewards]: validator.md#validation-rewards
 [g-output-payload-v0]: validator.md#output-payloadversion-0
 
@@ -29,9 +29,9 @@
 
 There are two types of network participants in the OP Stack:
 
-- [Sequencers](https://github.com/ethereum-optimism/optimism/blob/develop/specs/introduction.md#sequencers) consolidate
+- [Sequencers](https://specs.optimism.io/introduction.html#sequencers) consolidate
  users' on/off chain transactions into blocks. They submit checkpoint outputs as well as batch transactions.
-- [Verifiers](https://github.com/ethereum-optimism/optimism/blob/develop/specs/introduction.md#verifiers) verify rollup
+- [Verifiers](https://specs.optimism.io/introduction.html#verifiers) verify rollup
    integrity and dispute invalid assertions.
 
 It is crucial to have at least one honest verifier who can verify the integrity of the rollup chain to ensure the
@@ -75,7 +75,7 @@ be expanded to other clients for pragmatic decentralization.
 
 The `ValidatorRewardScalar` field was added to [system configuration][g-system-config].
 
-```
+```go
 type L1BlockInfo struct {
     Number    uint64
     Time      uint64
@@ -94,17 +94,16 @@ type L1BlockInfo struct {
 }
 ```
 
-<pre>
-<a href="https://github.com/kroma-network/kroma/blob/dev/op-node/rollup/derive/l1_block_info.go">Code link here</a>
-</pre>
+[Code here](https://github.com/kroma-network/kroma/blob/dev/op-node/rollup/derive/l1_block_info.go)
+
 This value is set via the `SystemConfig` contract on L1 and passed through the L2 derivation process and used as an
 ingredient in the reward calculation. (Detailed calculations : [Validation Rewards][g-validation-rewards])
 
 ### Adding field to Output Payload
 
 The `next_block_hash` field was added to [Output Payload][g-output-payload-v0].
 
-```
+```go
 type OutputV0 struct {
     StateRoot                Bytes32
     MessagePasserStorageRoot Bytes32
@@ -115,9 +114,8 @@ type OutputV0 struct {
 }
 ```
 
-<pre>
-<a href="https://github.com/kroma-network/kroma/blob/dev/op-service/eth/output.go">Code here</a>
-</pre>
+[Code here](https://github.com/kroma-network/kroma/blob/dev/op-service/eth/output.go")
+
 This value is used as an additional material for the [verification process][g-zk-fault-proof] of the fault
 proof system.
 It is used to validate the relationship between the Source OutputRootProof and Dest OutputRootProof, and the validation

specs/protocol/predeploys.md

@@ -54,7 +54,7 @@ Proxies are set at each possible predeploy address except for the `ProxyAdmin` a
 
 ## ProxyAdmin
 
-[Implementation](https://github.com/kroma-network/kroma/blob/main/packages/contracts/contracts/ProxyAdmin.sol)
+[Implementation](https://github.com/kroma-network/kroma/blob/main/packages/contracts/contracts/universal/ProxyAdmin.sol)
 
 Address: `0x4200000000000000000000000000000000000000`
 

specs/protocol/security-council.md

@@ -25,15 +25,17 @@ all actions are carried out through multi-sig transaction or governance processe
 When an undeniable bug occurs within the [ZK Fault Proof System](../glossary.md#zk-fault-proof), assets locked in
 Layer 2 may be exposed to potential risks. To prevent this, the Security Council has the authority to rectify such
 issues. The Security Council intervenes in cases where two valid and contradictory ZK proofs exist
-([ZK soundness error](../fault-proof/challenge.mdhallenge.md#dismiss-challenge)) or fail to prove with a valid proof
-([ZK completeness error](../fault-proof/challenge.mdhallenge.md#force-delete-output)). Their intervention aims to prevent invalid outputs from
-being finalized, thereby safeguarding the assets locked in Layer 2.
+([ZK soundness error](../fault-proof/challenge.md#dismiss-challenge)) or fail to prove with a valid proof
+([ZK completeness error](../fault-proof/challenge.md#force-delete-output)).
+Their intervention aims to prevent invalid outputs from being finalized,
+thereby safeguarding the assets locked in Layer 2.
 
 ## Guardian of Bridge
 
 If potential threats exposing Layer 2 assets within the Bridge, the Security Council possesses the authority to promptly
 pause/unpause the bridge through a multi-sig transaction. The `GUARDIAN` in the
-[`KromaPortal.sol`](../packages/contracts/contracts/L1/KromaPortal.sol) is configured to be Security Council.
+[`KromaPortal.sol`](https://github.com/kroma-network/kroma/blob/main/packages/contracts/contracts/L1/KromaPortal.sol)
+is configured to be Security Council.
 
 ```solidity
     /**

specs/protocol/validator.md

@@ -4,6 +4,7 @@
 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
 **Table of Contents**
 
+- [Overview](#overview)
 - [Submitting L2 Output Commitments](#submitting-l2-output-commitments)
 - [L2 Output Commitment Construction](#l2-output-commitment-construction)
   - [Output Payload(Version 0)](#output-payloadversion-0)
@@ -176,8 +177,8 @@ When submitting the output, the validator must bond Ethereum for `REQUIRED_BOND_
 rewarded to the L2 `ValidatorRewardVault` contract when the output is finalized.
 
 Also, validators should stake their bond for disputing challenge. This bond will be given to the winner of the challenge
-as a reward. When this reward distributed, a [tax](../fault-proof/challenge.md) is imposed to prevent collusive attacks of asserter
-and challenger.
+as a reward. When this reward distributed, a [tax](../fault-proof/challenge.md) is imposed to prevent collusive attacks
+of asserter and challenger.
 
 Validator Pool Smart Contract implements the following interface:
 

specs/protocol/withdrawals.md

@@ -20,7 +20,6 @@
 
 <!-- END doctoc generated TOC please keep comment here to allow auto update -->
 
-
 <!-- All glossary references in this file. -->
 
 [g-deposits]: ../glossary.md#deposits

specs/root.md

@@ -4,7 +4,6 @@
 This directory contains the plain english specs for Kroma, a minimal optimistic rollup protocol
 that maintains 1:1 compatibility with Ethereum.
 
-
 <!-- START doctoc generated TOC please keep comment here to allow auto update -->
 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
 **Table of Contents**