Updates and improves README

README.md

@@ -10,36 +10,36 @@
 >[!NOTE]
 >Polycash has no association with the Polygon blockchain, despite the similar naming.
 
-The home of a power-efficient, secure, quantum-resistant, and modern cryptocurrency blockchain designed to resolve the issues presented by the traditional PoW (Proof of Work) incentive mechanism while maintaining decentralization. Written in Golang and Rust for secure algorithm implementations, lightweight networking, memory safety, speed, and reliability.
+The home of a power-efficient, secure, quantum-resistant, and modern cryptocurrency blockchain designed to resolve the issues presented by the traditional PoW (Proof of Work) incentive mechanism while maintaining decentralization. Written in Golang, Rust, and C++.
 
 >[!TIP]
 >[Discussions](https://github.com/Ashy5000/cryptocurrency/discussions) are now available! You can use discussions for asking questions, giving feedback, or really anything else related to the project.
 
 ## Modified PoW protocol
 
-As opposed to the original Proof of Work (PoW) protocol, this blockchain does not calculate block difficulty on a global level. Instead, it is adjusted at a per-miner basis, mostly removing the reward for using more computing power and thus more energy. If a miner has a higher hash rate and thus initially mines blocks faster, they will be provided with higher difficulty blocks and will end up mining blocks at a **nearly constant rate** of _1 min/transaction_. The reason this is not exactly constant is that miners with a higher mining rate do receive slightly lower difficulties than necessary for the constant rate. At infinite computing power, a miner would theoretically have a 50% lower difficulty than expected: this is the lower boundary. A miner with zero computing power would theoretically have a 50% higher difficulty than expected: this is the upper boundary. Keep in mind that the difficulty is still lower for miners with a lower mining rate, but the ratio of difficulty to mining rate is higher with a lower mining rate. This motivates miners to contribute computing power to the network to keep it secure while still maintaining an increase in decentralization. In addition, the block difficulty is retargeted _every_ time a miner mines a block, ensuring quick reactions to changes in miner hash rates. To prevent miners from registering multiple private keys in an attempt to avoid the difficulty constraints, there is planned to be a high initial difficulty, or the constant difficulty for the first block a miner mines. In addition, the total number of miners at a time is limited to a maximum that increases as the blockchain's length grows. This prevents miners from using large amounts of computing resources and energy to create a large number of key pairs that have overcome the initial block.
+As opposed to the original Proof of Work (PoW) protocol, this blockchain does not calculate block difficulty on a global level. Instead, it is adjusted at a per-miner basis, mostly removing the reward for using more computing power and thus more energy. If a miner has a higher hash rate and thus initially mines blocks faster, they will be provided with higher difficulty blocks and will end up mining blocks at a **nearly constant rate** of _1 min/transaction_. The reason this is not exactly constant is that miners with a higher mining rate do receive slightly lower difficulties than necessary for the constant rate. At infinite computing power, a miner would theoretically have a 50% lower difficulty than expected: this is the lower boundary. A miner with zero computing power would theoretically have a 50% higher difficulty than expected: this is the upper boundary. Keep in mind that the difficulty is still lower for miners with a lower mining rate, but the ratio of difficulty to mining rate is higher with a lower mining rate. This motivates miners to contribute computing power to the network to keep it secure while still maintaining an increase in decentralization. In addition, the block difficulty is retargeted _every_ time a miner mines a block, ensuring quick reactions to changes in miner hash rates. To prevent miners from registering multiple private keys in an attempt to avoid the difficulty constraints, there are several safeguards put in place. First, miners are not rewarded for the first 3 blocks they mine, so creating multiple keys would cost a significant barrier to entry. Also, the block reward decreases by 1% for each new mining keypair that joins the network, so creating multiple keys becomes unprofitable, as it would damage the revenue of existing keys.
 
 ## Time Verification
 
 Using a new verification method, time verification, both the security and the performance of the blockchain are improved as compared to Proof of Work. This protocol can prevent malicious forks from occuring using nodes' verification of new blocks using the curent timestamp, requiring signatures from miner nodes to become valid. Setting rewards and limits for the number of valid signatures in a block strictly enforces the security of this protocol.
 
 ## Quantum-Resistant Signatures
 
-This blockchain utilizes the Dilithium3 signature algorithm, a quantum-resistant algorithm chosen as a winner for the NIST Post Quantum Cryptography standardization process.
+This blockchain utilizes the Dilithium3 signature algorithm, a quantum-resistant algorithm chosen as a winner for the NIST Post Quantum Cryptography standardization process. This is designed to future-proof the blockchain from the developing field of quantum computing.
 
 ## Roadmap
 
 The roadmap for this repository looks something like this:
 
-**Development** (COMPLETE): Implementing a blockchain and networking system, along with the specific changes to the PoW and networking protocols in order to increase the effectiveness, speed, reliability, and efficiency of the blockchain. Creating a README that documents the design decisions of the blockchain and network and how to use the software. Licensing the software with the GNU General Purpose License v3.0. Performing small scale, local tests on various operating systems and architectures to ensure the software works correctly.
+**Initial Development** (COMPLETE): Implementing a blockchain and networking system, along with the specific changes to the PoW and networking protocols in order to increase the effectiveness, speed, reliability, and efficiency of the blockchain. Creating a README that documents the design decisions of the blockchain and network and how to use the software. Licensing the software with the GNU General Purpose License v3.0. Performing small scale, local tests on various operating systems and architectures to ensure the software works correctly.
 
 **Testnet** (ACTIVE): Running a testing network to verfify the correct operation of the software. Expirementing with its ability to verify large amounts of transactions at once. Making adjustments if neccessary to increase the speed, reliability, and efficiency of the blockchain. Running small-scale tests on the cryptocurrency's financial model.
 
-**Production** (COMING UP): Launching the final product, fixing any issues if and when they arrive.
+**Mainnet** (COMING UP): Launching the final network, fixing any issues if and when they arrive.
 
 ## Directory structure
 
-The root directory of this project is occupied by the Golang source code that nodes run in order to interact with each other and the decentralized blockchain. In the `peer_server` directory, there is Rust code that can be run by servers to maintain a list of peers in the network. Nodes can connect to these servers or maintain their own lists. Using this code is optional, and its only purpose is to make it faster to discover peers. Thirdly, the `gui_wallet` directory contains Rust code for a GUI wallet to make transactions easier to make. Note that you will still have to generate a key using the `keygen` command in the interactive console (see _To run as a client_ below).
+The root directory of this project is occupied by the Golang source code that nodes run in order to interact with each other and the decentralized blockchain. The `gui_wallet` directory contains Rust code for a GUI wallet to make transactions easier to make. Note that you will still have to generate a key using the `keygen` command in the interactive console (see _To run as a client_ below). The `vm` directory contains a Rust project capable of running smart contracts on the blockchain's virtual machine. The CMake project in the `language` directory forms the compiler for Polylang, a high-level language that compiles to `.blockasm` files, which can be run on the blockchain's virtual machine.
 
 ## Setup & Usage
 >[!IMPORTANT]