fix broken links in upgrade 1.8 guide :doc

docs/20_upgrade-guide/81_1.8-upgrade-guide.md

@@ -41,9 +41,9 @@ The BPs should then set this chosen time in the configuration JSON file for the
 
 It is important that this configuration change happens prior to allowing that node to produce blocks on the network. As long as more than two-thirds of the active block producers have set the same future time in the configuration file for the `PREACTIVATE_FEATURE` on their BP nodes, the network will be safe from any attempts at premature activation by some other active BP.
 
-After the agreed upon time has passed, any of the active block producers can activate the `PREACTIVATE_FEATURE` protocol feature with a simple request sent to the [`producer_api_plugin`](../03_plugins/producer_api_plugin/index.md) of their BP node.
+After the agreed upon time has passed, any of the active block producers can activate the `PREACTIVATE_FEATURE` protocol feature with a simple request sent to the [`producer_api_plugin`](../01_nodeos/03_plugins/producer_api_plugin/index.md) of their BP node.
 
-To determine the specific format of the request, the digest of the `PREACTIVATE_FEATURE` protocol feature must first be determined. This can be found by looking at nodeos startup logs, or by sending a request to the `get_supported_protocol_features` endpoint provided by the [`producer_api_plugin`](../03_plugins/producer_api_plugin/index.md). 
+To determine the specific format of the request, the digest of the `PREACTIVATE_FEATURE` protocol feature must first be determined. This can be found by looking at nodeos startup logs, or by sending a request to the `get_supported_protocol_features` endpoint provided by the [`producer_api_plugin`](../01_nodeos/03_plugins/producer_api_plugin/index.md). 
 
 Send a request to the endpoint locally: 
 
@@ -121,9 +121,9 @@ Once the `PREACTIVATE_FEATURE` protocol feature has been activated, the [new sys
 Block explorers, exchanges, and applications building on the blockchain can all follow the four-step processes described above to upgrade their nodes in time and ensure their services continue when the first protocol upgrade is activated. However, they should also be aware that certain protocol features change the behavior of existing operations on the blockchain, and in some cases also slightly change the structure of blocks and transactions.
 
 
-**First**, v1.8 changes the structure of transaction traces, even prior to the activation of any protocol features. Clients consuming transaction and action traces made available through [`history_plugin`](../03_plugins/history_plugin/index.md), [`mongo_db_plugin`](../03_plugins/mongo_db_plugin/index.md), or [`state_history_plugin`](../03_plugins/state_history_plugin/index.md) should be aware of the changes made to the trace structure (see details at [#7044](https://github.com/EOSIO/eos/pull/7044) and [#7108](https://github.com/EOSIO/eos/pull/7108)). Clients consuming the trace output of the `push_transaction` RPC from the chain API should not need to do anything since the output of that RPC should be backwards compatible. However, they are encouraged to replace usage of `push_transaction` with the new RPC [`send_transaction`](https://developers.eos.io/eosio-nodeos/reference#send_transaction) which uses the new flat structure to store the action traces.
+**First**, v1.8 changes the structure of transaction traces, even prior to the activation of any protocol features. Clients consuming transaction and action traces made available through [`history_plugin`](../01_nodeos/03_plugins/history_plugin/index.md), [`mongo_db_plugin`](../01_nodeos/03_plugins/mongo_db_plugin/index.md), or [`state_history_plugin`](../01_nodeos/03_plugins/state_history_plugin/index.md) should be aware of the changes made to the trace structure (see details at [#7044](https://github.com/EOSIO/eos/pull/7044) and [#7108](https://github.com/EOSIO/eos/pull/7108)). Clients consuming the trace output of the `push_transaction` RPC from the chain API should not need to do anything since the output of that RPC should be backwards compatible. However, they are encouraged to replace usage of `push_transaction` with the new RPC [`send_transaction`](https://developers.eos.io/eosio-nodeos/reference#send_transaction) which uses the new flat structure to store the action traces.
 
-The [`state_history_plugin`](../03_plugins/state_history_plugin/index.md) has also changed its API and the structure of the files it stores on disk in a backwards incompatible way in v1.8. These changes reflect, among other things, the transaction trace structural changes and the data structure changes made within the chain state database to support the new protocol features. Consumers of the [`state_history_plugin`](../03_plugins/state_history_plugin/index.md) will need to be updated to work with the new changes in v1.8.
+The [`state_history_plugin`](../01_nodeos/03_plugins/state_history_plugin/index.md) has also changed its API and the structure of the files it stores on disk in a backwards incompatible way in v1.8. These changes reflect, among other things, the transaction trace structural changes and the data structure changes made within the chain state database to support the new protocol features. Consumers of the [`state_history_plugin`](../01_nodeos/03_plugins/state_history_plugin/index.md) will need to be updated to work with the new changes in v1.8.
 
 **Second**, all protocol features are activated by signaling their 256-bit digest through a block. The block producer is able to place the digest of a protocol feature in a special section of the block header (called the block header extensions) that, under the original rules of v1.7, is expected to be empty. This change may especially be relevant to block explorers which need to ensure that their tools will not break because of the extra data included in the block header and ideally will update their block explorers to reflect the new information. The first time block explorers or other consumers of the blockchain data will encounter a non-empty block header extension is during the activation of the `PREACTIVATE_FEATURE` protocol feature.