docs: fix bad formatting

AztecProtocol · Apr 22, 2024 · a4139a4 · a4139a4
1 parent 17d0e0d
commit a4139a4
Show file tree

Hide file tree

Showing 6 changed files with 8 additions and 13 deletions.
diff --git a/docs/docs/developers/aztecjs/guides/call_view_function.md b/docs/docs/developers/aztecjs/guides/call_view_function.md
@@ -31,7 +31,6 @@ Call the `simulate` function on the typescript contract wrapper like this:
 #include_code simulate_function yarn-project/end-to-end/src/composed/docs_examples.test.ts typescript
 
 :::info Note
-
 - If the simulated function is `unconstrained` you will get a properly typed value.
 - If the simulated function is `public` or `private` it will return a Field array of size 4.
-  :::
+:::
diff --git a/docs/docs/developers/contracts/writing_contracts/events/emit_event.md b/docs/docs/developers/contracts/writing_contracts/events/emit_event.md
@@ -91,10 +91,9 @@ Unencrypted events are events which can be read by anyone.
 They can be emitted by both public and private functions.
 
 :::danger
-
 - Emitting unencrypted events from private function is a significant privacy leak and it should be considered by the developer whether it is acceptable.
 - Unencrypted events are currently **NOT** linked to the contract emitting them, so it is practically a [`debug_log`](../oracles/main.md#a-few-useful-inbuilt-oracles).
-  :::
+:::
 
 ### Call emit_unencrypted_log
 

diff --git a/docs/docs/protocol-specs/contract-deployment/classes.md b/docs/docs/protocol-specs/contract-deployment/classes.md
@@ -12,7 +12,7 @@ Read the following discussions for additional context:
 - [Abstracting contract deployment](https://forum.aztec.network/t/proposal-abstracting-contract-deployment/2576)
 - [Implementing contract upgrades](https://forum.aztec.network/t/implementing-contract-upgrades/2570)
 - [Contract classes, upgrades, and default accounts](https://forum.aztec.network/t/contract-classes-upgrades-and-default-accounts/433)
-  :::
+:::
 
 ## `ContractClass`
 

diff --git a/docs/docs/protocol-specs/data-publication-and-availability/overview.md b/docs/docs/protocol-specs/data-publication-and-availability/overview.md
@@ -27,7 +27,7 @@ From distributed systems, the _security_ of a protocol or system is defined by:
 
 - **Liveness**: Eventually something good will happen.
 - **Safety**: Nothing bad will happen.
-  :::
+:::
 
 In the context of blockchain, this _security_ is defined by the confirmation rule, while this can be chosen individually by the user, our validating light node (L1 bridge) can be seen as a user, after all, it's "just" another node.
 For the case of a validity proof based blockchain, a good confirmation rule should satisfy the following sub-properties (inspired by [Sreeram's framing](https://twitter.com/sreeramkannan/status/1683735050897207296)):

diff --git a/docs/docs/protocol-specs/decentralization/block-production.md b/docs/docs/protocol-specs/decentralization/block-production.md
@@ -24,12 +24,11 @@ We should probably introduce the PXE somewhere
 | RAM     | 32gb    | 64gb        |
 
 :::info Estimates
-
 - **CPU**: Help
 - **Network**: 40KB for a transaction with proof (see [P2P network](./p2p-network.md#network-bandwidth)). Assuming gossiping grows the data upload/download 10x, ~400KB per tx. With 10 tx/s that's 4MB/s or 32mb/s.
 - **Storage**: [~1548 bytes per transaction](../data-publication-and-availability/index.md#aztec-specific-data) + tree overhead, ~ 0.4 TB per year.
 - **RAM**: Help
-  :::
+:::
 
 ### Sequencers
 
@@ -106,14 +105,13 @@ Anyone ->> Network: eligible as a sequencer
 ## Block production
 
 :::danger **TODO**
-
 - The diagram needs to be updated with respect to "VRF".
 - In **Prover commitment** phase, it is not said what the signature is used for. I'm expecting that it is used to allow the prover to publish the message on behalf of the sequencer, but it is not made clear.
 - In **Backup** phase, would be useful if we add a comment on the duration
 - In Diagram
   - add a dedicated timeline from the block production's PoV
   - get rid of "pre-confirmed"
-    :::
+:::
 
 ![Governance Summary Image](/img/protocol-specs/decentralization/Aztec-Block-Production-1.png)
 

diff --git a/docs/docs/protocol-specs/l1-smart-contracts/index.md b/docs/docs/protocol-specs/l1-smart-contracts/index.md
@@ -12,7 +12,7 @@ The purpose of the L1 contracts are simple:
 
 - Facilitate cross-chain communication such that L1 liquidity can be used on L2
 - Act as a validating light node for L2 that every L1 node implicitly run
-  :::
+:::
 
 ## Overview
 
@@ -488,10 +488,9 @@ Also, some of the conditions are repetitions of what we saw earlier from the [st
     - The consumer contract SHOULD check that the message exists in the state
 
 :::info
-
 - For cost purposes, it can be useful to commit to the public inputs to just pass a single value into the circuit.
 - Time constraints might change depending on the exact sequencer selection mechanism.
-  :::
+:::
 
 ## Logical Execution