fix broken links

chain/chunks/README.md

@@ -2,7 +2,7 @@
 
 This crate cotains functions to handle chunks. In NEAR - the block consists of multiple chunks - at most one per shard.
 
-When a chunk is created, the creator encodes its contents using Reed Solomon encoding (ErasureCoding) and adds cross-shard receipts - creating PartialEncodedChunks that are later sent to all the validators (each validator gets a subset of them). This is done for data availability reasons (so that we need only a part of the validators to reconstruct the whole chunk). You can read more about it in the Nightshade paper (https://near.org/nightshade/)
+When a chunk is created, the creator encodes its contents using Reed Solomon encoding (ErasureCoding) and adds cross-shard receipts - creating PartialEncodedChunks that are later sent to all the validators (each validator gets a subset of them). This is done for data availability reasons (so that we need only a part of the validators to reconstruct the whole chunk). You can read more about it in [the Nightshade paper](https://near.org/papers/nightshade).
 
 
 A honest validator will only approve a block if it receives its assigned parts for all chunks in the block - which means that for each chunk, it has `has_all_parts()` returning true.

chain/epoch-manager/README.md

@@ -21,7 +21,7 @@ EpochManager has also a lot of methords that allows you to fetch information fro
 
 ## RewardCalculator
 RewardCalculator is responsible for computing rewards for the validators at the end of the epoch, based on their block/chunk productions.
-You can see more details on the https://nomicon.io/Economics/README.html#validator-rewards-calculation
+You can see more details on [the Nomicon documentation](https://nomicon.io/Economics/Economic#validator-rewards-calculation).
 
 ## Validator Selection / proposals / proposals_to_epoch_info
 These files/functions are responsible for selecting the validators for the next epoch (and internally - also deciding which validator will produce which block and which chunk).

chain/rosetta-rpc/README.md

@@ -110,11 +110,11 @@ in production and will be located at `./target/release/neard`.
 
 Alternatively, during development and testing it may be better to
 follow the method recommended when [contributing to
-nearcore](https://docs.near.org/docs/community/contribute/contribute-nearcore)
+nearcore](https://github.com/near/nearcore/blob/master/CONTRIBUTING.md)
 which creates a slightly less optimised executable but does it faster:
 
 ```bash
-cargo build --release --package neard --bin neard
+cargo build --profile dev-release --package neard --bin neard
 ```
 
 ## How to Configure

docs/architecture/README.md

@@ -255,7 +255,7 @@ starting point when reading the code base.
 
 The [tracing](https://tracing.rs) crate is used for structured, hierarchical
 event output and logging. We also integrate [Prometheus](https://prometheus.io)
-for light-weight metric output. See the [style](./style.md) documentation for
+for light-weight metric output. See the [style](../practices/style.md) documentation for
 more information on the usage.
 
 ### Testing

docs/architecture/gas/estimator.md

@@ -76,7 +76,7 @@ cloud-hosted VMs) and manual labor to set it up.
 
 The other supported metric `icount` is much more stable. It uses
 [qemu](https://www.qemu.org/) to emulate an x86 CPU. We then insert a custom
-[TCG plugin](https://qemu.readthedocs.io/en/latest/devel/tcg-plugins.html)
+[TCG plugin](https://www.qemu.org/docs/master/devel/tcg-plugins.html)
 ([counter.c](https://github.com/near/nearcore/blob/08c4a1bd4b16847eb1c2fccee36bf16f6efb71fd/runtime/runtime-params-estimator/emu-cost/counter_plugin/counter.c))
 that counts the number of executed x86 instructions. It also intercepts system
 calls and counts the number of bytes seen in `sys_read`, `sys_write` and their