diff --git a/docs/Designs/Bridge.md b/docs/Designs/Bridge.md
index 1773ccd..0f051b5 100644
--- a/docs/Designs/Bridge.md
+++ b/docs/Designs/Bridge.md
@@ -1,5 +1,5 @@
---
-sidebar_position: 4
+sidebar_position: 5
---
# Bridge to L1/L2
@@ -26,7 +26,6 @@ The bridge, a technological masterpiece, comprises a set of intelligent contract
It is worth noting that this bridge is just one of the many possibilities built on top of zkEVM, and it serves as a testament to the platform's immense potential. In fact, anyone can leverage the signal service to build bridges, which underscores the flexibility and scalability of this innovative platform. If you're curious about the bridge, you can explore its features and functionalities by [trying it out yourself](https://wannsee).
-
## How to bridge ETH
Even though ETH is not the default gas fee in MXC zkEVM, there is still a possibility to bridge and use ETH on the platform. This is made possible by the existence of Wrapped ETH [(WETH)](https://arbiscan.io/token/0x82af49447d8a07e3bd95bd0d56f35241523fbab1) in the Arbitrum chain, which can be effortlessly ported to MXC SupernodeV2 using the bridge.
diff --git a/docs/Designs/DA.md b/docs/Designs/DA.md
index e04f253..00d1955 100644
--- a/docs/Designs/DA.md
+++ b/docs/Designs/DA.md
@@ -1,8 +1,9 @@
---
-sidebar_position: 9
+sidebar_position: 10
---
# Data Availability
+
> With the MXC zkEVM DA module leveraging IPNS for data storage, only state roots and a necessary subset of transaction data are sent to Arbitrum (L2), while the bulk of the transaction batch data is posted to IPNS. For decentralized applications (dApps) with high gas consumption, they can operate at the same cost as a standard transaction (like a transfer) on MXC zkEVM, and the Arbitrum fee will not escalate with the complexity of L3 transaction execution. As a result, for transactions of high complexity, this approach can save up to approximately 70% of the cost compared to traditional L2 rollup fees on Arbitrum.
:::tip Ontario Upgrade
diff --git a/docs/Designs/Gas.md b/docs/Designs/Gas.md
index 38039c2..b7ec86c 100644
--- a/docs/Designs/Gas.md
+++ b/docs/Designs/Gas.md
@@ -1,6 +1,7 @@
---
-sidebar_position: 8
+sidebar_position: 9
---
+
# Gas Fee for Layer3
There are two parties a user pays when submitting a tx:
@@ -16,7 +17,7 @@ The L3 component consists of the traditional fees Geth would pay to stakers in a
Every zkEVM transaction has two costs: An L3 (execution) fee and an L2 (security) fee. At a high level, the L3 fee is the cost to execute your transaction in L3 and the L2 fee is the estimated cost to publish your transaction on L2 (in a rollup batch). Typically the L2 security fee is much higher than the L3 execution fee, so if you can wait it makes sense to postpone transactions until gas prices are lower (for example, over the weekend).
-L3 execution fee is charged as tx.gasPrice * l3GasUsed (up to tx.gasLimit). You can check the current L3 gas price in explorer. The transaction gas price is composed of two components: a base fee and a priority fee, because we are EIP 1559 compliant (although with different parameter values).
+L3 execution fee is charged as tx.gasPrice \* l3GasUsed (up to tx.gasLimit). You can check the current L3 gas price in explorer. The transaction gas price is composed of two components: a base fee and a priority fee, because we are EIP 1559 compliant (although with different parameter values).
L2 security fee that pays for the cost of publishing the transaction on L2 (the cost of Ethereum equivalent security). It is deducted automatically from the supernode's ETH balance on Arbitrum One. It is based on three factors that are multiplied together:
diff --git a/docs/Designs/Hexagons.md b/docs/Designs/Hexagons.md
index 9090b1a..6c9ff5f 100644
--- a/docs/Designs/Hexagons.md
+++ b/docs/Designs/Hexagons.md
@@ -1,18 +1,19 @@
---
-sidebar_position: 10
+sidebar_position: 11
---
## Hexagon-Based Geographical Partitioning
-
### Concept Overview:
+
- **World Segmentation**: Divides the world into approximately 98 million hexagonal cells.
- **Hexagon Dimensions**: Each hexagon covers an area of roughly 5 km², with a diameter of about 2 km.
- **Origin Point**: The hexagonal grid originates in Berlin, Germany, serving as the anchor point for this global grid system.
### Technical Details:
+
- **H3 Geospatial Indexing**: Utilizes the H3 Geospatial Indexing Framework, as detailed on [H3Geo's documentation](https://h3geo.org/docs/core-library/restable/).
- **Resolution Choice**: MXC has selected 'Resolution 7' for this grid, balancing granularity and computational efficiency.
- **Balance of Detail and Efficiency**: The resolution choice balances the detail of geospatial data and the processing efficiency.
@@ -20,20 +21,24 @@ sidebar_position: 10
## Privacy Considerations
### Key Feature:
+
- **Privacy through Hexagons**: Enhanced privacy through hexagon-based geolocation.
- **Hexagon ID Sharing**: Users share only their hexagon ID, not precise coordinates.
### Privacy Mechanism:
+
- **Location Ambiguity**: By sharing just a hexagon ID, an individual's exact location remains ambiguous within a 5 km² area.
- **Reduced Tracking Risk**: This system significantly reduces the risk of location tracking and personal data exposure.
## Web3 Integration
### Core Concept:
+
- **Web3 Native Design**: The system is inherently Web3-oriented, integrating seamlessly with decentralized technologies.
- **Unique Hexagon Identification**: Hexagons can be uniquely identified and interacted with using MXC domain names (e.g., berlin.mxc).
### Applications:
+
- **Infrastructure for DApps**: Provides a robust infrastructure for DApps (Decentralized Applications) focusing on geolocation-based services.
- **Innovative Applications**: Enables innovative applications such as secure tracking systems and decentralized Point of Interest (DePIN) inscriptions.
@@ -42,7 +47,7 @@ sidebar_position: 10
ES6 usage:
```js
-import {latLngToCell} from "h3-js";
+import { latLngToCell } from "h3-js";
```
CommonJS usage:
@@ -73,7 +78,6 @@ const hexBoundary = h3.cellToBoundary(h3Index);
// -> [ [37.341099093235684, -122.04156135164334 ], ...]
```
-
## Name a hexagon
The hexagons can be indexed and named using MNS : https://doc.mxc.com/docs/Tutorials/name-hexagon#5-navigate-back-to-wannsee-mns-and-set-hexagon-to-your-domain-name
diff --git a/docs/Designs/LPWAN.md b/docs/Designs/LPWAN.md
index 21e520f..21a6bf9 100644
--- a/docs/Designs/LPWAN.md
+++ b/docs/Designs/LPWAN.md
@@ -1,5 +1,5 @@
---
-sidebar_position: 3
+sidebar_position: 4
---
# IoT LPWAN Protocol
@@ -18,12 +18,11 @@ A more detailed illustration is as follows:
MEP stands for MXC Evolution Proposal. Each MEP will be a proposal document providing information to the MXC zkEVM ecosystem and community.
-
Here is the list of subjects of MEPs:
-| MEP Number | Title | Type | Status |
-| --------------------------------- | -------------------------------------------------------- | --------- | ------ |
-| [MEP-1](https://github.com/MXCzkEVM/MEPs/tree/main/proposals/mep-1.md) | Purpose and Guidelines | Process | Living |
+| MEP Number | Title | Type | Status |
+| ---------------------------------------------------------------------------- | -------------------------------------------------------- | --------- | ------ |
+| [MEP-1](https://github.com/MXCzkEVM/MEPs/tree/main/proposals/mep-1.md) | Purpose and Guidelines | Process | Living |
| [MEP-20](https://github.com/MXCzkEVM/MEPs/tree/main/proposals/mep-20.md) | Tokens Standrds on MXC zkEVM Chain | Standards | Living |
| [MEP-721](https://github.com/MXCzkEVM/MEPs/tree/main/proposals/mep-721.md) | Non-Fungible Token Standard on MXC zkEVM Chain | Standards | Draft |
| [MEP-801](https://github.com/MXCzkEVM/MEPs/tree/main/proposals/mep-801.md) | ISO Application Contract | Standards | Draft |
@@ -32,8 +31,6 @@ Here is the list of subjects of MEPs:
| [MEP-804](https://github.com/MXCzkEVM/MEPs/tree/main/proposals/mep-804.md) | ISO Reward Token Contract | Standards | Draft |
| [MEP-1002](https://github.com/MXCzkEVM/MEPs/tree/main/proposals/mep-1002.md) | Nestable Non-Fungible Tokens Tied to IoT Geolocations | Standards | Living |
| [MEP-1004](https://github.com/MXCzkEVM/MEPs/tree/main/proposals/mep-1004.md) | Non-Fungible Tokens Tied to IoT Radio Base Station Miner | Standards | Living |
-| [MEP-1759](https://github.com/MXCzkEVM/MEPs/tree/main/proposals/mep-1759.md) | MXC DApp Store Metadata Standard | Standards | Living|
+| [MEP-1759](https://github.com/MXCzkEVM/MEPs/tree/main/proposals/mep-1759.md) | MXC DApp Store Metadata Standard | Standards | Living |
| [MEP-600](https://github.com/MXCzkEVM/MEPs/tree/main/proposals/mep-600.md) | NFT NFC Contract | Standards | Draft |
-| [MEP-2542](https://github.com/MXCzkEVM/MEPs/tree/main/proposals/mep-2542.md) | Multi-Token Mining for MEP-1004 Radio Miners | Standards | Living |
-
-
+| [MEP-2542](https://github.com/MXCzkEVM/MEPs/tree/main/proposals/mep-2542.md) | Multi-Token Mining for MEP-1004 Radio Miners | Standards | Living |
diff --git a/docs/Designs/Low-Scale-Certification.md b/docs/Designs/Low-Scale-Certification.md
index 9d04437..96b6dd5 100644
--- a/docs/Designs/Low-Scale-Certification.md
+++ b/docs/Designs/Low-Scale-Certification.md
@@ -1,6 +1,7 @@
---
-sidebar_position: 7
+sidebar_position: 8
---
+
# Low-Scale-Certification
## Table of Contents
@@ -74,51 +75,51 @@ sidebar_position: 7
- [4.4.3 SNR](#443-snr)
- [4.4.4 Combining the methods](#444-combining-the-methods)
-
## Chapter 1 Definitions
+
### 1.1 LPWAN
-Low-Power Wide-Area Network is a type of wireless telecommunication network designed to facilitate long-range communication between low-power devices at low bit rates.
-This technology is particularly suited for Internet of Things (IoT) applications and sensor networks, where devices need to transmit small amounts of data over long distances while consuming minimal power.
+Low-Power Wide-Area Network is a type of wireless telecommunication network designed to facilitate long-range communication between low-power devices at low bit rates.
+
+This technology is particularly suited for Internet of Things (IoT) applications and sensor networks, where devices need to transmit small amounts of data over long distances while consuming minimal power.
LPWAN offers cost-effective and energy-efficient connectivity solutions for various industries, including agriculture, smart cities, logistics, and environmental monitoring.
+### 1.2 MXC Blockchain
-
-### 1.2 MXC Blockchain
-is a decentralized, open-source blockchain platform specifically designed to support the Internet of Things (IoT) ecosystem and machine-to-machine (M2M) communication.
+is a decentralized, open-source blockchain platform specifically designed to support the Internet of Things (IoT) ecosystem and machine-to-machine (M2M) communication.
By leveraging the benefits of distributed ledger technology, MXC aims to create a more efficient, secure, and transparent environment for IoT devices and applications. The platform enables device interoperability, facilitates data sharing, and ensures secure data transactions among connected devices. Additionally, MXC Blockchain incentivizes users through its native cryptocurrency, the MXC token, which can be utilized for various purposes within the network, such as device registration, data transactions, and participation in network governance.
### 1.3 Low Scale Certification
-Low Scale Certification (LSC) is a process designed to verify the physical existence and location of objects, such as IoT devices and sensors, within a specific area or network.
+Low Scale Certification (LSC) is a process designed to verify the physical existence and location of objects, such as IoT devices and sensors, within a specific area or network.
-LSC is employed to address the limitations of conventional proof of location methods by providing a more secure and reliable means of confirming an object's location and physical existence.
+LSC is employed to address the limitations of conventional proof of location methods by providing a more secure and reliable means of confirming an object's location and physical existence.
-The benefits of LSC include enhanced security, reduced risk of spoofing or tampering, and increased trust in the authenticity of the verified objects.
+The benefits of LSC include enhanced security, reduced risk of spoofing or tampering, and increased trust in the authenticity of the verified objects.
By leveraging LSC, networks can establish a more robust foundation for location-based services and applications, ensuring that the data being processed is genuine and accurate.
### 1.4 Consensus Group
-A Consensus Group is a set of network participants responsible for reaching an agreement on the state or decisions of a distributed system, such as a blockchain.
+A Consensus Group is a set of network participants responsible for reaching an agreement on the state or decisions of a distributed system, such as a blockchain.
These participants work together to validate transactions, maintain the integrity of the network, and ensure that the system operates securely and efficiently. This is achieved through the use of consensus algorithms that promote security, network integrity, and fault tolerance.
The specific rules and protocols governing the formation and operation of a Consensus Group can vary depending on the underlying blockchain or distributed ledger technology being used.
-Consensus Groups play a crucial role in maintaining the overall health and stability of a distributed system. They are often decentralized and open, which fosters transparent, fair, and democratic decision-making processes. This structure also contributes to the network's resilience by preventing single points of failure and reducing the risk of centralized control or manipulation.
+Consensus Groups play a crucial role in maintaining the overall health and stability of a distributed system. They are often decentralized and open, which fosters transparent, fair, and democratic decision-making processes. This structure also contributes to the network's resilience by preventing single points of failure and reducing the risk of centralized control or manipulation.
In summary, Consensus Groups are essential components of blockchain and distributed ledger technologies, as they help to uphold the core principles of security, decentralization, and trust.
### 1.5 Quorum
-A quorum is the minimum number of nodes or participants within a Consensus Group that must agree on a decision or transaction for it to be considered valid.
+A quorum is the minimum number of nodes or participants within a Consensus Group that must agree on a decision or transaction for it to be considered valid.
-The quorum ensures that a sufficient level of agreement and participation is achieved, promoting network stability, security, and consistency. The specific quorum requirements may vary depending on the consensus algorithm or network protocol in use.
+The quorum ensures that a sufficient level of agreement and participation is achieved, promoting network stability, security, and consistency. The specific quorum requirements may vary depending on the consensus algorithm or network protocol in use.
By requiring a quorum, distributed networks can prevent malicious actors from taking control of the system or manipulating the ledger, as they would need to compromise a significant portion of the Consensus Group to succeed.
@@ -128,14 +129,13 @@ A quorum in a consensus group refers to the minimum number of participants or no
### 1.6 2.4 GHz Miners
-2.4 GHz LPWAN (Low Power Wide Area Network) Miners are devices that participate in the operation of a wireless network designed for long-range communication and low power consumption.
+2.4 GHz LPWAN (Low Power Wide Area Network) Miners are devices that participate in the operation of a wireless network designed for long-range communication and low power consumption.
These miners operate in the 2.4 GHz frequency band, which is a globally available and unlicensed spectrum commonly used for various wireless communication technologies, such as Wi-Fi and Bluetooth.
-
-2.4 GHz LPWAN Miners contribute to the MXC network by verifying and validating transactions, maintaining the blockchain ledger, and facilitating secure communication between devices.
+2.4 GHz LPWAN Miners contribute to the MXC network by verifying and validating transactions, maintaining the blockchain ledger, and facilitating secure communication between devices.
They are optimized for energy efficiency and long-range connectivity, making them suitable for IoT applications and remote monitoring scenarios.
@@ -143,14 +143,12 @@ The 2.4 GHz LPWAN miners contribute to the MXC ecosystem by validating transacti
### 1.7 sub GHz Miners
-Sub GHz LPWAN Miners are devices that participate in the operation of a Low Power Wide Area Network designed for long-range communication and low power consumption, similar to 2.4 GHz LPWAN Miners. However, these miners operate in the sub-GHz frequency bands, such as 868 MHz in Europe or 915 MHz in North America.
+Sub GHz LPWAN Miners are devices that participate in the operation of a Low Power Wide Area Network designed for long-range communication and low power consumption, similar to 2.4 GHz LPWAN Miners. However, these miners operate in the sub-GHz frequency bands, such as 868 MHz in Europe or 915 MHz in North America.
Sub GHz LPWAN Miners are particularly well-suited for applications requiring more extensive coverage or better penetration through obstacles, as the lower frequencies generally provide improved range and signal propagation characteristics compared to the 2.4 GHz band.
-
-
Like their 2.4 GHz counterparts, Sub GHz LPWAN Miners contribute to the MXC network by verifying transactions, maintaining the blockchain ledger, and enabling secure communication between devices. They are also optimized for energy efficiency and extended connectivity, making them an ideal choice for IoT applications and remote monitoring situations.
Similar to the 2.4 GHz LPWAN miners, Sub GHz LPWAN miners also participate in validating transactions, consensus groups, and maintaining the connection between the physical world and the metaverse.
@@ -163,19 +161,24 @@ By connecting the Earth and the metaverse through MXC Hexagons, the MXC ecosyste
MXC Hexagons can be used to address various network planning and deployment challenges, such as:
-#### 1.8.1 Coverage Optimization:
+#### 1.8.1 Coverage Optimization:
+
By arranging LPWAN Miners in a hexagonal pattern, network planners can ensure optimal coverage and signal strength for IoT devices within the network. The hexagonal grid provides a more uniform and consistent coverage area compared to other shapes, like squares or circles, minimizing coverage gaps and signal degradation. Each hexagon is around 2 kilometer in diameter
-#### 1.8.2 Network Scalability:
+#### 1.8.2 Network Scalability:
+
The hexagonal model allows for easy expansion and scalability of the network as new LPWAN Miners are deployed. As the network grows, additional hexagons can be added to the grid, seamlessly integrating with the existing coverage areas and maintaining optimal connectivity.
-#### 1.8.3 Resource Allocation:
+#### 1.8.3 Resource Allocation:
+
MXC Hexagons can be used to allocate resources and responsibilities among LPWAN Miners within the network. By dividing the coverage area into hexagonal zones, network operators can assign specific tasks or roles to the miners within each hexagon, such as data processing, transaction validation, or network synchronization, optimizing the overall performance and efficiency of the system.
-#### 1.8.4 Network Visualization:
+#### 1.8.4 Network Visualization:
+
The hexagonal grid provides an intuitive and easy-to-understand representation of the network's coverage and connectivity. Network operators, IoT device manufacturers, and end-users can quickly grasp the network layout, signal strength, and Miner distribution by examining the MXC Hexagons, aiding in network planning, troubleshooting, and device deployment decisions.
-#### 1.8.5 Hexagons and Consensus Groups:
+#### 1.8.5 Hexagons and Consensus Groups:
+
MXC Hexagons also play a vital role in the formation and operation of Consensus Groups within the MXC ecosystem. By organizing the LPWAN Miners into hexagonal zones, the network can more effectively distribute the responsibility for validating transactions and maintaining the blockchain ledger among the miners.
Each hexagon can be associated with a specific Consensus Group, consisting of miners located within that hexagonal zone. This localized approach allows for faster and more efficient consensus decision-making, as miners within a given hexagon are likely to have stronger connectivity and lower latency compared to miners spread across the entire network.
@@ -188,46 +191,52 @@ By integrating MXC Hexagons with the Consensus Group structure, the MXC ecosyste
### 2.1 Logic of design
-#### 2.1.1 Problem definition
-The lack of a robust connection or bridge between the physical world (Earth) and the metaverse has led to challenges in ensuring the authenticity of devices and assets within the network.
+#### 2.1.1 Problem definition
+
+The lack of a robust connection or bridge between the physical world (Earth) and the metaverse has led to challenges in ensuring the authenticity of devices and assets within the network.
The absence of a reliable link between the two worlds makes it easier for malicious actors to introduce fake devices and compromise the network's security, undermining trust and the integrity of the virtual economy.
-#### 2.1.2 Current designs
-Various existing solutions have attempted to bridge the gap between the physical and virtual worlds to some extent.
+#### 2.1.2 Current designs
-One example is augmented reality (AR) technologies, which overlay digital information onto the real world, allowing users to interact with virtual objects and environments in a more immersive manner.
+Various existing solutions have attempted to bridge the gap between the physical and virtual worlds to some extent.
+
+One example is augmented reality (AR) technologies, which overlay digital information onto the real world, allowing users to interact with virtual objects and environments in a more immersive manner.
Another example is the use of blockchain technology to create digital tokens representing real-world assets, enabling the secure and transparent exchange of ownership and value across the virtual realm.
However, these solutions often fall short in providing a seamless and secure connection between the two worlds, leaving room for potential vulnerabilities and misrepresentations of digital assets.
-#### 2.1.3 Goal of design
-The primary aim of the design is to establish a seamless connection between the metaverse and the physical world, ensuring the authenticity and security of devices and assets within the network.
+#### 2.1.3 Goal of design
+
+The primary aim of the design is to establish a seamless connection between the metaverse and the physical world, ensuring the authenticity and security of devices and assets within the network.
By implementing robust proof of physical existence mechanisms, the design will protect the virtual economy from fraudulent activities and enable the traceability of items from the metaverse back to their real-world counterparts.
-#### 2.1.4 Prerequisite
-To build this secure and interconnected system, it is essential that network objects be certified by Low-Scale Certification (LSC).
+#### 2.1.4 Prerequisite
-LSC provides a foundation of trust and verification for devices and assets, ensuring that only genuine and authenticated objects are allowed to participate in the network and interact within the metaverse.
+To build this secure and interconnected system, it is essential that network objects be certified by Low-Scale Certification (LSC).
+
+LSC provides a foundation of trust and verification for devices and assets, ensuring that only genuine and authenticated objects are allowed to participate in the network and interact within the metaverse.
This prerequisite is crucial in realizing the vision of bridging the gap between the physical world and the metaverse, promoting a secure and trustworthy environment for users and network participants.
-#### 2.1.5 Advantage live tracking and mirroring
+#### 2.1.5 Advantage live tracking and mirroring
-One of the key advantages of this system is its ability to track items in both the physical and metaverse worlds in real-time. The location of an item in the physical world is accurately mirrored in the virtual metaverse, ensuring a consistent representation of objects and assets across both domains.
+One of the key advantages of this system is its ability to track items in both the physical and metaverse worlds in real-time. The location of an item in the physical world is accurately mirrored in the virtual metaverse, ensuring a consistent representation of objects and assets across both domains.
This live tracking capability allows users and network participants to seamlessly interact with and verify the presence of objects in both worlds, enhancing the overall user experience and trust in the system.
-By maintaining an accurate and live reflection of objects in the metaverse that corresponds to their real-world counterparts, the system promotes greater transparency, accountability, and security.
+By maintaining an accurate and live reflection of objects in the metaverse that corresponds to their real-world counterparts, the system promotes greater transparency, accountability, and security.
Users can confidently engage with the virtual environment, knowing that what they see and interact with in the metaverse is a genuine representation of the physical world. This live tracking and mirroring functionality not only strengthens the connection between the two worlds but also serves as a foundation for building innovative applications and services that take advantage of this seamless and reliable integration.
### 2.2 Synchronization of miners in the network
#### 2.2.1 Importance Of Synchronization
+
Achieving precise synchronization between the miners in the network is essential to maintain a seamless connection between the physical world and the metaverse. Synchronization ensures the integrity of data and transactions, while enabling real-time tracking and mirroring of objects across both domains. Proper synchronization prevents data corruption and ensures that the devices on the network operate coherently, providing users with a reliable and secure experience.
-#### 2.2.2 Our Synchronization Goal
+#### 2.2.2 Our Synchronization Goal
+
The system is designed to maintain real-time synchronization among the miners, devices, and the blockchain to support the live tracking of objects in both the physical world and the metaverse. To achieve this, the system utilizes nanosecond timekeeping, which enables an extremely accurate level of synchronization among all network components.
By synchronizing the miners with the blockchain and connected devices, the system ensures that all changes and operations in the network are accurately timestamped and recorded. This high degree of synchronization allows for a consistent representation of objects and assets across the physical and virtual worlds, providing users with a trustworthy environment in which to engage and interact.
@@ -235,28 +244,35 @@ By synchronizing the miners with the blockchain and connected devices, the syste
The precise synchronization between miners, devices, and the blockchain forms the foundation for a robust and secure system, enabling the development of innovative applications and services that take advantage of the seamless connection between the physical world and the metaverse.
#### 2.2.3 Synchronization Methods And Challenges
+
Achieving precise synchronization between miners and the network is a challenging task. Various methods, such as the Network Time Protocol (NTP) or the Precision Time Protocol (PTP), can be employed to synchronize miners with the network. However, these methods may not be sufficient to achieve the desired nanosecond-level synchronization. Implementing more advanced techniques, such as atomic clocks or GPS-based time synchronization, can help improve synchronization accuracy. Overcoming challenges, such as network latency, clock drift, and signal propagation delays, is essential for maintaining a well-synchronized network.
#### 2.2.4 Impact Of Synchronization On Network Performance And Security
+
Precise synchronization plays a vital role in ensuring the overall performance and security of the network. Improved synchronization enables miners to process transactions more efficiently, reduces the likelihood of data corruption, and enhances the overall network resilience against attacks. By maintaining accurate time synchronization, the network can better detect and mitigate various security threats, such as replay attacks or time manipulation attempts. Furthermore, precise synchronization also improves the system's ability to track items and mirror their location data in both the physical world and the metaverse.
### 2.3 Trustworthy Location
#### 2.3.1 Importance of accurate location
+
Ensuring the accurate representation of a device's location in both the real world and the metaverse is crucial for maintaining the integrity of the network and the seamless connection between the two domains. Accurate location information helps protect the network from potential attacks, in which malicious actors may attempt to disrupt the system by providing false location data for devices. Moreover, as the hexagon grid plays a vital role in the consensus group, accurate location data is essential for the proper functioning of the MXC blockchain and LPWAN devices.
#### 2.3.2 Goal of accurate location
+
The system aims to establish a secure and reliable connection between the metaverse, the devices using the network (such as LPWAN miners), and the MXC blockchain. By providing accurate and untampered location data through the use of hexagons as a representation of the metaverse grid, the system ensures that location information can be checked, traced, and trusted by the public. This approach makes it more challenging for attackers to compromise the network, as the location data is transparent and verifiable, promoting a more secure environment for users and network participants. Through this method, the system reinforces the trustworthiness of the connection between the physical world and the metaverse, fostering a reliable foundation for the development of innovative applications and services.
#### 2.3.3 Trustworthy Location Verification Techniques
+
Several techniques can be employed to ensure accurate and trustworthy location data in the network. These may include time difference of arrival (TDoA), received signal strength indicator (RSSI), and signal-to-noise ratio (SNR) measurements. Combining multiple location verification techniques can further improve location accuracy and reliability, making it more challenging for attackers to manipulate or falsify the data.
#### 2.3.4 The Role Of The Consensus Group In Maintaining Trustworthy Location Data
+
The consensus group plays an essential part in maintaining trustworthy location data in the MXC blockchain. By participating in the validation and confirmation of location information, the consensus group members help ensure that the data remains accurate and consistent throughout the network. This collaborative approach, in conjunction with the use of blockchain technology, provides a transparent, decentralized, and secure environment for location data management. Consequently, it upholds the seamless connection between the physical world and the metaverse and the overall integrity of the network.
### 2.4 Trustworthy Physical Existence
#### 2.4.1 Why Establishing Trustworthiness in Proving Object Existence
+
Establishing trustworthiness in proving the physical existence of objects is crucial for several reasons. By verifying the existence of a device in our system, we ensure that it is an authentic device, with a genuine physical presence, and not just a digital entity. Trustworthy proof of existence plays a vital role in:
- Security and fraud prevention: By confirming the physical existence of devices, we can protect the network from fake devices and malicious actors seeking to exploit the system.
@@ -265,9 +281,11 @@ Establishing trustworthiness in proving the physical existence of objects is cru
- Quality control and performance monitoring: Trustworthy proof of existence allows for better monitoring of device performance and maintaining a high level of quality control in the network.
#### 2.4.2 Challenges in Ensuring Trustworthy Proof of Existence Methods
+
The challenge lies in devices made by third-party manufacturers wanting to connect to the network. Ensuring that these devices meet the necessary requirements and standards for proving their physical existence can be a complex and resource-intensive process.
#### 2.4.3 Goal of Physical Existence Verification
+
The primary goal of physical existence verification is to provide proof of physicality that is verifiable, traceable, and trusted by the public. By establishing trustworthy proof of existence, we can protect the network from fake devices that might disturb the network's functionality and security. This helps maintain the seamless connection between the physical world and the metaverse and ensures the integrity and reliability of the MXC network.
## Chapter 3 LSC of physical existence for miners and sensors
@@ -275,70 +293,76 @@ The primary goal of physical existence verification is to provide proof of physi
### 3.1 Decentralized LSC Solution
#### 3.1.1 LSC Device Provisioning
+
##### Definition
-- **Low-Scale Certification (LSC):**
-is a technology used to prove the existence of a Low Power Wide Area Network (LPWAN) device in the real world. It is crucial in applications where LPWAN end-devices perform tasks that require interactions with the blockchain. Establishing a strategy for detecting and minimizing the risk of malicious actions by actors pretending to be real, physical devices is essential. In this context, we introduce the concept of LSC - the multilevel network verification of existence.
-- **Device provisioning:**
-is the process of establishing a shared secret key between the device and the cloud server to exchange information securely and encrypted. The protocol is based on the Key exchange protocol that uses asymmetric cryptography and is based on the PID (unique device identifier). The device manufacturer purchases the PID from the SuperNode for a fee.
+- **Low-Scale Certification (LSC):**
+ is a technology used to prove the existence of a Low Power Wide Area Network (LPWAN) device in the real world. It is crucial in applications where LPWAN end-devices perform tasks that require interactions with the blockchain. Establishing a strategy for detecting and minimizing the risk of malicious actions by actors pretending to be real, physical devices is essential. In this context, we introduce the concept of LSC - the multilevel network verification of existence.
+- **Device provisioning:**
+ is the process of establishing a shared secret key between the device and the cloud server to exchange information securely and encrypted. The protocol is based on the Key exchange protocol that uses asymmetric cryptography and is based on the PID (unique device identifier). The device manufacturer purchases the PID from the SuperNode for a fee.
##### Method
+
Our method for LSC device provisioning involves three steps:
-- **Generate the PID:**
-The PID is created by the Device owner on the Super Node using the MEP. The PID costs a fee. The SuperNode then creates an NFT on the blockchain with the PID attached to a secret, only visible to the owner of the NFT. The NFT is then sent to the Creator's wallet.
-
+- **Generate the PID:**
+ The PID is created by the Device owner on the Super Node using the MEP. The PID costs a fee. The SuperNode then creates an NFT on the blockchain with the PID attached to a secret, only visible to the owner of the NFT. The NFT is then sent to the Creator's wallet.
+ 
+- **Program the PID into the device:**
+ The owner needs to flash the PID into the sensor device it wants to produce. They also need to print a label with the PID so the device can be added to the Data Dash app by scanning it.
-- **Program the PID into the device:**
-The owner needs to flash the PID into the sensor device it wants to produce. They also need to print a label with the PID so the device can be added to the Data Dash app by scanning it.
+- **Device provisioning:**
+ PID is just an authenticator of the device; to join, the device needs to perform self-provisioning after it is manufactured.
-- **Device provisioning:**
-PID is just an authenticator of the device; to join, the device needs to perform self-provisioning after it is manufactured.
+Two types of keys should be created and exchanged during this process
-Two types of keys should be created and exchanged during this process
-- *AS128 keys for LPWAN, and*
-- *ECC keys for authentication and signing.*
+- _AS128 keys for LPWAN, and_
+- _ECC keys for authentication and signing._
-The AS128 key will be stored on the Device Provisioning server.
-The Public ECC key will be stored on the blockchain, and
+The AS128 key will be stored on the Device Provisioning server.
+The Public ECC key will be stored on the blockchain, and
the Private ECC key will be only known to the device itself.
The provisioning message sent by the Sensor Device is forwarded to the SuperNode by the Miner, who signs the message with its private key.
-
-The Miner has its Public Key stored on the blockchain because it was provisioned earlier, so we know it is real.
-The SuperNode generates all the keys and sends the AS128 and ECC keys to the Device.
-At the same time, it signs the received signed message from the Miner with its own private key and creates a new NFT with this message chain and Device Public key and attaches it to the original NFT with PID on the blockchain.
+The Miner has its Public Key stored on the blockchain because it was provisioned earlier, so we know it is real.
+The SuperNode generates all the keys and sends the AS128 and ECC keys to the Device.
+At the same time, it signs the received signed message from the Miner with its own private key and creates a new NFT with this message chain and Device Public key and attaches it to the original NFT with PID on the blockchain.
The NFT can contain more information like the EUI of the device, the certificate of the manufacturer, and so on.
#### 3.1.2 Prerequisites for the Solutions:
+
To participate in the decentralized LSC solution, there are two prerequisites that an owner can choose from:
-##### Staking Stable Coins
+##### Staking Stable Coins
+
Users must stake a certain amount of stable coins as collateral to ensure their commitment to the network and its security.
+
##### Link To A Social Profile
+
Users must link their accounts to a social media profile to increase transparency and trustworthiness within the network. This connection helps deter malicious actors from attempting to manipulate or deceive the network.
### 3.2 Benefits Of Decentralized LSC Solution
+
The decentralized Low-Scale Certification (LSC) solution aims to address the challenges of ensuring the authenticity of devices and assets within the metaverse and the physical world. By leveraging blockchain technology, the solution provides a secure, transparent, and tamper-resistant way to verify the existence of devices and assets. This is crucial for maintaining the integrity and security of the network, as well as fostering trust among users and participants.
The decentralized nature of the LSC solution offers several key advantages:
- **Security:**
-By distributing the certification process across multiple nodes in the network, the decentralized LSC solution mitigates the risk of a single point of failure. This makes it more difficult for malicious actors to compromise the system, ensuring the security of devices and assets.
+ By distributing the certification process across multiple nodes in the network, the decentralized LSC solution mitigates the risk of a single point of failure. This makes it more difficult for malicious actors to compromise the system, ensuring the security of devices and assets.
- **Transparency:**
-The LSC solution utilizes blockchain technology, which inherently provides a transparent and auditable record of device certification. This allows users and participants to verify the authenticity of devices and assets easily, promoting trust within the network.
+ The LSC solution utilizes blockchain technology, which inherently provides a transparent and auditable record of device certification. This allows users and participants to verify the authenticity of devices and assets easily, promoting trust within the network.
- **Scalability:**
-As the number of devices and assets within the metaverse and the physical world continues to grow, a centralized certification system may struggle to keep up with the demand. The decentralized LSC solution is inherently more scalable, as it can distribute the certification workload across multiple nodes in the network.
+ As the number of devices and assets within the metaverse and the physical world continues to grow, a centralized certification system may struggle to keep up with the demand. The decentralized LSC solution is inherently more scalable, as it can distribute the certification workload across multiple nodes in the network.
- **Flexibility:**
-The decentralized LSC solution allows for more flexible device provisioning and certification processes. By enabling devices to self-provision and participate in the network, the solution can accommodate a wider range of devices and manufacturers.
+ The decentralized LSC solution allows for more flexible device provisioning and certification processes. By enabling devices to self-provision and participate in the network, the solution can accommodate a wider range of devices and manufacturers.
By implementing the decentralized LSC solution, the system can establish a seamless and secure connection between the metaverse and the physical world, ensuring the authenticity and security of devices and assets within the network. This, in turn, promotes a more reliable and trustworthy environment for users and network participants, laying the foundation for innovative applications and services that leverage the interconnectedness of the two worlds.
@@ -356,111 +380,120 @@ Once the miner's registration and location have been confirmed, it then links up
-
The consensus group then grows and expands, with each group verifying the locations of other consensus groups. The more substantial groups absorb the smaller ones, with the ultimate goal being the formation of a single, dominant consensus group. This growth and merging process is crucial for maintaining the network's stability and security, making it resistant to attacks and failures.
#### 4.1.2 What Influences the Consensus Algorithm
-A miner's score is a critical factor in determining its eligibility to join a consensus group. This score is a combination of two metrics:
-- Miner Peer Listening and
-- Miner fuel.
-The total score of the miners within a group, rather than the average score, determines the strength of the consensus group.
+A miner's score is a critical factor in determining its eligibility to join a consensus group. This score is a combination of two metrics:
+
+- Miner Peer Listening and
+- Miner fuel.
+ The total score of the miners within a group, rather than the average score, determines the strength of the consensus group.
#### 4.1.3 Prerequisites for Joining a Consensus Group
-Before a device can join a consensus group,
-- it must have been provisioned and
-- must have a miner score of at least 510 points.
- - The score is divided between Miner Peer Listening and Miner Fuel.
+Before a device can join a consensus group,
+
+- it must have been provisioned and
+- must have a miner score of at least 510 points.
+ - The score is divided between Miner Peer Listening and Miner Fuel.
Miner Peer Listening:
-Each hexagon can hold up to
-- 10 sub-GHz or
-- 50 2.4-GHz miners
+Each hexagon can hold up to
+
+- 10 sub-GHz or
+- 50 2.4-GHz miners
for the miner score system. When a hexagon is fully populated, it suggests that each miner is trustworthy.
This metric carries a weight of 49% in the miner's total score.
Miner Fuel:
-This metric reflects the number of tokens held within the miner's. A full 100% capacity equates to a 51% score, which makes the miner eligible to join a consensus group.
+This metric reflects the number of tokens held within the miner's. A full 100% capacity equates to a 51% score, which makes the miner eligible to join a consensus group.
The tokens in the tank are not only a sign of the miner's authenticity but also an indication of the owner's commitment to the network. This metric carries a weight of 51% in the miner's total score.
### 4.2 Consensus Group Ground Rules:
#### 4.2.1 Definitions
+
A Consensus Group serves as the collective consciousness of the MXC blockchain, following established protocols and formed under certain conditions. It represents a group of Miners, bound by the law of Quorum, which governs decision-making and merging dynamics within the group.
#### 4.2.2 Commitment to Implementation:
-The Consensus Group plays a pivotal role in the MXC blockchain, with responsibilities that include overseeing LPWAN devices and enforcing network rules and procedures.
-A core component of these rules is the establishment of certain prerequisites that every miner must meet to qualify for membership in a consensus group.
+The Consensus Group plays a pivotal role in the MXC blockchain, with responsibilities that include overseeing LPWAN devices and enforcing network rules and procedures.
-These prerequisites serve as safeguards, protecting the network and its miners from potential threats posed by non-compliant entities. Furthermore, these requirements ensure the validity of device locations, thus preserving the overall integrity of the network.
+A core component of these rules is the establishment of certain prerequisites that every miner must meet to qualify for membership in a consensus group.
-Any breach of these rules triggers specific protective measures taken by the Consensus Group to mitigate possible risks to the network.
+These prerequisites serve as safeguards, protecting the network and its miners from potential threats posed by non-compliant entities. Furthermore, these requirements ensure the validity of device locations, thus preserving the overall integrity of the network.
+
+Any breach of these rules triggers specific protective measures taken by the Consensus Group to mitigate possible risks to the network.
The ensuing sections provide a comprehensive discussion of these requirements and measures.
+
- Validation of Miner location.
- Miner bound to Location.
- Exit fee to unbind from location
-
#### 4.2.3 Validation
-Before the Consensus Group formation, LPWAN devices validate their location via the DataDash app. Simultaneously, miner metric scores are verified to ensure data accuracy and miner authenticity.
+
+Before the Consensus Group formation, LPWAN devices validate their location via the DataDash app. Simultaneously, miner metric scores are verified to ensure data accuracy and miner authenticity.
It is essential that each Miner be bound to a specific coordinate within a hexagon with a minimal margin of error.
#### 4.2.4 Binding Scenario
+
By default, the Miner Owner binds the Miner's location to a coordinate within a hexagon free of charge, later enabling it to join a Consensus Group and reap its benefits. The miner can only mine if it is bound to a hexagon.
-This binding is essential for mining and remains effective for a block time duration after joining a hexagon.
+This binding is essential for mining and remains effective for a block time duration after joining a hexagon.
If the Miner fails to join a Consensus Group within this timeframe, an exit fee must be paid for re-binding.
The Exit fee will be explained in the next section.
#### 4.2.5 Exit Fee
-- **Definition of Exit Fee:**
- - The exit fee is a payment required when a miner, previously bound to a specific location in a Consensus Group, needs to be unbound.
- - This fee becomes necessary when a miner's location changes, as it would then no longer be part of its original Consensus Group. Hence, the fee covers the cost of unbinding the miner from its current location, allowing for its relocation and subsequent entry into a new consensus group.
+
+- **Definition of Exit Fee:**
+
+ - The exit fee is a payment required when a miner, previously bound to a specific location in a Consensus Group, needs to be unbound.
+ - This fee becomes necessary when a miner's location changes, as it would then no longer be part of its original Consensus Group. Hence, the fee covers the cost of unbinding the miner from its current location, allowing for its relocation and subsequent entry into a new consensus group.
- **Functions of the Exit Fee:**
- - A miner, by default, is bound to a particular location before its entry into a consensus group. If the miner's location changes while bound, the miner will be disallowed from mining or utilizing the network.
- - If a miner wishes to change its location or Consensus Group, the miner's owner must pay a fixed fee to unbind it from its current location. This requirement stands even if the miner is expelled from the Consensus Group; the fee is still necessary to unbind it from the location.
+
+ - A miner, by default, is bound to a particular location before its entry into a consensus group. If the miner's location changes while bound, the miner will be disallowed from mining or utilizing the network.
+ - If a miner wishes to change its location or Consensus Group, the miner's owner must pay a fixed fee to unbind it from its current location. This requirement stands even if the miner is expelled from the Consensus Group; the fee is still necessary to unbind it from the location.
- **Benefits of the Exit Fee:**
- - It discourages frequent changes to a miner's location, as users will likely be hesitant to repeatedly pay the fee.
- - In case of a miner being under attack, the miner will cease operations, thereby limiting potential harm.
- - The exit fee mechanism ensures that a miner is strictly bound to a specific location, i.e., a particular hexagon. The payment of the exit fee provides the necessary step to unbind a miner from its location, thereby maintaining network integrity.
+ - It discourages frequent changes to a miner's location, as users will likely be hesitant to repeatedly pay the fee.
+ - In case of a miner being under attack, the miner will cease operations, thereby limiting potential harm.
+ - The exit fee mechanism ensures that a miner is strictly bound to a specific location, i.e., a particular hexagon. The payment of the exit fee provides the necessary step to unbind a miner from its location, thereby maintaining network integrity.
**Scenarios:**
+
1. **Relocation by Miner Owner:**
-In instances where the Miner Owner is relocating to a new place, the Miner Owner is required to pay the exit fee to unbind the miner from its original location. This allows the miner to be re-registered at the new location.
-
+ In instances where the Miner Owner is relocating to a new place, the Miner Owner is required to pay the exit fee to unbind the miner from its original location. This allows the miner to be re-registered at the new location.
+ 
-2. **Miner Malfeasance:**
-If a miner is detected to be launching attacks on the network, it will be expelled from its Consensus Group. However, should the miner wish to join a new Consensus Group, the Miner Owner will be required to pay the exit fee to unbind the miner from its current location, thus allowing for its re-entry into a different Consensus Group.
-
+2. **Miner Malfeasance:**
+ If a miner is detected to be launching attacks on the network, it will be expelled from its Consensus Group. However, should the miner wish to join a new Consensus Group, the Miner Owner will be required to pay the exit fee to unbind the miner from its current location, thus allowing for its re-entry into a different Consensus Group.
+ 
-3. **Temporary Relocation:**
-In a situation where the Miner Owner temporarily relocates along with the miner to a different location, the Miner Owner has two options. The Miner Owner can choose to pay the exit fee to register the miner at the temporary location or refrain from paying the fee until they return to the original location where the miner is bound.
-
+3. **Temporary Relocation:**
+ In a situation where the Miner Owner temporarily relocates along with the miner to a different location, the Miner Owner has two options. The Miner Owner can choose to pay the exit fee to register the miner at the temporary location or refrain from paying the fee until they return to the original location where the miner is bound.
+ 
4. **Miner Attack:**
-If a miner is being subjected to attacks at the hardware level or the peer listening level, it may appear as if the miner is transmitting an incorrect location, seeming to be located in a different city/town/district/hexagon. Since the Miner Owner has the ability to decide whether or not to pay the exit fee to relocate the bound location of the miner, the miner can be safeguarded from this type of manipulation. During the attack, the miner will not participate in the Consensus Group until it returns to its bound location. This protects the network from potential harm, whether the miner is under attack or if the Miner Owner is launching an attack on the network.
+ If a miner is being subjected to attacks at the hardware level or the peer listening level, it may appear as if the miner is transmitting an incorrect location, seeming to be located in a different city/town/district/hexagon. Since the Miner Owner has the ability to decide whether or not to pay the exit fee to relocate the bound location of the miner, the miner can be safeguarded from this type of manipulation. During the attack, the miner will not participate in the Consensus Group until it returns to its bound location. This protects the network from potential harm, whether the miner is under attack or if the Miner Owner is launching an attack on the network.
#### 4.2.6 Formation
+
The formation of a Consensus Group is a process that starts with smaller, individual units coming together to form a larger, more cohesive group.
- **Initial Grouping:** The formation of a Consensus Group begins with the establishment of smaller clusters. These clusters will merge with each other to create a larger, unified Consensus Group.
- **Group Composition:** A Consensus Group comprises at least three miners. For Sub GHz miners, each miner must be in a different hexagon. Conversely, for 2.4 GHz miners, all three should be located within the same hexagon.
- **Score Threshold:** Each miner participating in the Consensus Group must have a miner score of 510 or above.
-
+ 
- **Location Validation:** The miners within a Consensus Group verify each other's locations using Time Difference of Arrival (TDoA) and Received Signal Strength Indicator (RSSI) measurements. These measurements allow each miner to determine the distance to other miners, which is equivalent to the radius of a circle centered on the miner. The miner is expected to be located along the circumference of this circle. The Miner Owner's uploaded coordinates, which were provided when the miner was bound to its location, should intersect with this calculated circumference, thus confirming the validity of the miner's location.
-
-
-
-
+ 
#### 4.2.7 Flexibility
+
Resilience and adaptability are fundamental to the Consensus Group's operation. The architecture of the Consensus Group is designed to be highly flexible, capable of deconstructing and reforming with different miners as circumstances dictate. This ability to adapt is crucial in responding to shifts in the network or changes in miner behavior.
If an issue arises with a miner, the Consensus Group's flexibility allows for swift and smooth resolution. The problematic miner can be replaced seamlessly without destabilizing the group's function or integrity. Alternatively, if necessary, the entire Consensus Group can disband and be replaced by a new one. This interchangeability helps maintain the group's optimal performance and assures continuous coverage of its designated area.
@@ -468,6 +501,7 @@ If an issue arises with a miner, the Consensus Group's flexibility allows for sw
This flexibility, in essence, enables the Consensus Group to evolve dynamically with the network, maintaining optimal efficiency and responsiveness in the face of changing circumstances. Whether it's miner turnover or unexpected disruptions, the Consensus Group's adaptability ensures it can accommodate these shifts and continue to function effectively.
#### 4.2.8 Data Aggregation
+
Data aggregation is an integral process in the Consensus Group's operations. It involves the collection and synthesis of data from all Low-Power Wide-Area Network (LPWAN) devices under the group's governance. Through comprehensive data aggregation, the Consensus Group can ensure that its decision-making processes are informed by the most complete and accurate data set possible.
Key data points gathered in this process include:
@@ -479,21 +513,20 @@ Key data points gathered in this process include:
- **Bound Locations:** Every miner is bound to a specific location within the Consensus Group. Data on these bound locations is vital for overseeing network operation and maintaining its structure.
- **Consensus Group Affiliations:** Knowing which Consensus Group each miner belongs to is key to understanding the overall layout and organization of the network.
-| bound Location | miners | miner score | Consensus group | Consensus group total | location true | meet min condition |
-| -------------- | --------- | ----------- | --------------- | --------------------- | ------------- | ------------- |
-| 1 | alpha.mxc | 657 | green | 1726 | True | True |
-| 2 | bravo.mxc | 510 | green | 1726 | True | True |
-| 3 | charlie.mxc | 559 | green | 1726 | True | True |
-| 4 | delta.mxc | 608 | yellow | 1677 | True | True |
-| 5 | echo.mxc | 559 | yellow | 1677 | True | True |
-| 6 | foxtrot.mxc | 510 | yellow | 1677 | True | True |
-| 7 | golf.mxc | 657 | red | 1873 | True | True |
-| 8 | hotel.mxc | 559 | red | 1873 | True | True |
-| 9 | india.mxc | 657 | red | 1873 | True | True |
-| 10 | juliett.mxc | 510 | blue | 2118 | True | True |
-| 11 | kilo.mxc | 755 | blue | 2118 | True | True |
-| 12 | lima.mxc | 853 | blue | 2118 | True | True |
-
+| bound Location | miners | miner score | Consensus group | Consensus group total | location true | meet min condition |
+| -------------- | ----------- | ----------- | --------------- | --------------------- | ------------- | ------------------ |
+| 1 | alpha.mxc | 657 | green | 1726 | True | True |
+| 2 | bravo.mxc | 510 | green | 1726 | True | True |
+| 3 | charlie.mxc | 559 | green | 1726 | True | True |
+| 4 | delta.mxc | 608 | yellow | 1677 | True | True |
+| 5 | echo.mxc | 559 | yellow | 1677 | True | True |
+| 6 | foxtrot.mxc | 510 | yellow | 1677 | True | True |
+| 7 | golf.mxc | 657 | red | 1873 | True | True |
+| 8 | hotel.mxc | 559 | red | 1873 | True | True |
+| 9 | india.mxc | 657 | red | 1873 | True | True |
+| 10 | juliett.mxc | 510 | blue | 2118 | True | True |
+| 11 | kilo.mxc | 755 | blue | 2118 | True | True |
+| 12 | lima.mxc | 853 | blue | 2118 | True | True |
By diligently aggregating these extensive sets of data, the Consensus Group can maintain a holistic and detailed understanding of the network's state. This promotes effective oversight, facilitates the early detection of potential issues, and ensures the network continues to function efficiently and securely.
@@ -513,8 +546,9 @@ This safeguard is in place to prevent any unilateral decisions, fostering a tran
#### 4.3.2 Decision-Making Process
-The decision-making process in a Consensus Group hinges upon the accurate determination of device locations. This process engages two miner Consensus Groups, each adhering to the stipulated minimums:
-- three miners located in distinct hexagons for sub-GHz miners, and
+The decision-making process in a Consensus Group hinges upon the accurate determination of device locations. This process engages two miner Consensus Groups, each adhering to the stipulated minimums:
+
+- three miners located in distinct hexagons for sub-GHz miners, and
- three miners situated within the same hexagon for 2.4 GHz miners.
These groups exchange essential data and follow established rules for mutual verification. They also engage an auxiliary Consensus Group when confronted with discrepancies or potential threats that warrant further examination.
@@ -523,57 +557,57 @@ Each Consensus Group undertakes a thorough verification of miner locations in th
A mutual agreement, represented by 51% or more of each cluster, that all locations have been appropriately verified, triggers the consolidation process. The group with the higher cumulative score consumes the lower scoring group, leading to a merger that unifies both clusters into a single, larger entity. This procedure aligns with our fundamental principle of bigger, higher-scoring groups absorbing smaller, lower-scoring ones, reinforcing network stability and unity.
-| location | miners | miner score | delta.mxc | echo.mxc | foxtrot.mxc |
-| --- | --- | --- | --- | --- | --- |
-| 1 | alpha.mxc | 657 | correct | correct | correct |
-| 2 | bravo.mxc | 510 | correct | correct | correct |
-| 3 | charlie.mxc | 559 | correct | correct | correct |
+| location | miners | miner score | delta.mxc | echo.mxc | foxtrot.mxc |
+| --------- | ------------------ | ------------------------ | ----------- | ----------- | ----------- |
+| 1 | alpha.mxc | 657 | correct | correct | correct |
+| 2 | bravo.mxc | 510 | correct | correct | correct |
+| 3 | charlie.mxc | 559 | correct | correct | correct |
| ave score | 1726/3000 = 57.53% | loc. correct probability | 57.53% at 4 | 57.53% at 5 | 57.53% at 6 |
-| | | | alpha.mxc | bravo.mxc | charlie.mxc |
-| 4 | delta.mxc | 608 | correct | correct | correct |
-| 5 | echo.mxc | 559 | correct | correct | correct |
-| 6 | foxtrot.mxc | 510 | correct | correct | correct |
-| ave score | 1677/3000 = 55.9% | loc. correct probability | 55.9% at 1 | 55.9% at 2 | 55.9% at |
+| | | | alpha.mxc | bravo.mxc | charlie.mxc |
+| 4 | delta.mxc | 608 | correct | correct | correct |
+| 5 | echo.mxc | 559 | correct | correct | correct |
+| 6 | foxtrot.mxc | 510 | correct | correct | correct |
+| ave score | 1677/3000 = 55.9% | loc. correct probability | 55.9% at 1 | 55.9% at 2 | 55.9% at |
#### 4.3.3 Scenarios
Consensus Groups are formed with the primary intention of evaluating each other to determine which one will absorb the other. This can lead to several potential scenarios:
- Scenario 1: Consensus Group 1 possesses a higher score than Consensus Group 2. In this situation, Consensus Group 1, being superior, takes over Consensus Group 2, incorporating it into its structure.
-
+ 
- Scenario 2: Both Consensus Groups have identical scores but a varying number of miners. Here, the group with fewer miners gains precedence and takes over the larger Consensus Group. This decision hinges on the principle of promoting efficiency and reducing unnecessary redundancy.
-
-
+ 
- Scenario 3: Both Consensus Groups have equal scores and an equal number of miners. The resolution of this deadlock is achieved through a random selection of the group to take precedence and absorb the other.
-
+ 
- Scenario 4: A Consensus Group faces challenges in validation due to certain miners. The problematic miners are disbanded from the group, and new, qualified miners replace them to restore functionality.
-
+ 
- Scenario 5: A large Consensus Group is assessing another group, but some miners are unable to communicate with their counterparts due to the sheer scale of the group. In this case, a sub-Consensus Group forms, composed of miners that can engage with the target group. This sub-group then leads the evaluation process.
-
+ 
These scenarios reflect the adaptability and robustness of the consensus decision-making process, allowing for flexibility in various circumstances while maintaining the integrity and functionality of the network.
### 4.4 Localization
-Localization is a critical factor in our Consensus Group model, affecting the network's overall integrity and efficiency. Three important measures are employed to achieve this:
-- Time Difference of Arrival (TDoA),
-- Received Signal Strength Indicator (RSSI), and
+Localization is a critical factor in our Consensus Group model, affecting the network's overall integrity and efficiency. Three important measures are employed to achieve this:
+
+- Time Difference of Arrival (TDoA),
+- Received Signal Strength Indicator (RSSI), and
- Signal-to-Noise Ratio (SNR).
-#### 4.4.1 TDoA
+#### 4.4.1 TDoA
-Time Difference of Arrival TDoA is a method for determining the position of a wireless device by measuring the time difference of signal arrival from the device to several receivers (miners in our case).
+Time Difference of Arrival TDoA is a method for determining the position of a wireless device by measuring the time difference of signal arrival from the device to several receivers (miners in our case).
As the speed of the radio wave is known, these time differences can be translated into distances, thereby pinpointing the device's location. This method is particularly useful for verifying miner locations in the Consensus Group.
-#### 4.4.2 RSSI
+#### 4.4.2 RSSI
Received Signal Strength Indicator RSSI is a measurement of the power present in a received radio signal. This measure can provide an estimate of the distance between the miner and the LPWAN device, as signal strength generally diminishes with increased distance. RSSI plays a critical role in validating the locations of devices within the network, ensuring that the miner's reported location aligns with the expected signal strength.
-#### 4.4.3 SNR
+#### 4.4.3 SNR
Signal-to-Noise Ratio SNR measures the ratio of the power of a signal (meaningful information) to the power of background noise (unwanted signal). Higher SNR values indicate cleaner, higher quality signals which are easier to distinguish from the noise. SNR can be used to estimate the quality of the signal received by miners, and therefore can indirectly infer their proximity to the LPWAN devices.
@@ -581,4 +615,4 @@ Signal-to-Noise Ratio SNR measures the ratio of the power of a signal (meaningfu
Combining TDoA, RSSI, and SNR methods results in a more robust and reliable location estimation system. TDoA provides a primary location estimation, while RSSI and SNR offer supportive data to refine these estimations and validate them. This synergistic combination allows for more accurate determination of device locations, even in challenging network conditions.
-The blend of these methods benefits the overall Consensus Group model by enhancing the certainty and accuracy of miner localizations. This, in turn, supports the key principles of the model, from the formation of Consensus Groups to the decision-making process and beyond. By ensuring correct device localizations, we reinforce the trustworthiness of the network, optimize network efficiency, and maintain the integrity of our LPWAN infrastructure.
\ No newline at end of file
+The blend of these methods benefits the overall Consensus Group model by enhancing the certainty and accuracy of miner localizations. This, in turn, supports the key principles of the model, from the formation of Consensus Groups to the decision-making process and beyond. By ensuring correct device localizations, we reinforce the trustworthiness of the network, optimize network efficiency, and maintain the integrity of our LPWAN infrastructure.
diff --git a/docs/Designs/Proposing.md b/docs/Designs/Proposing.md
index 58d466d..b5a9e08 100644
--- a/docs/Designs/Proposing.md
+++ b/docs/Designs/Proposing.md
@@ -1,5 +1,5 @@
---
-sidebar_position: 1
+sidebar_position: 2
---
# Proposing MXC Blocks
@@ -8,10 +8,9 @@ On MXC zkEVM, the next L2 state is known immediately and deterministically at th
## Proposing the L2 zk MXC Blocks to L1
-
1. Block is proposed by any proposer (permissionlessly).
2. Block level properties are checked validity by TaikoL1 contract ([proposed block intrinsic validity function](https://taiko.xyz/docs/concepts/creating-taiko-blocks/intrinsic-validity-functions#proposed-block-intrinsic-validity-function)).
3. Proposed block is downloaded by a MXC Supernode, and the transaction list is parsed over and checked for validity ([transaction list intrinsic validity function](https://taiko.xyz/docs/concepts/creating-taiko-blocks/intrinsic-validity-functions#transaction-list-intrinsic-validity-function)).
- - IF every transaction in the list is valid, an ordered subset of the list is created by skipping over transactions which have an invalid nonce or the sender has too little MXC balance to pay for the transaction. This ordered subset is used along with the [anchor transaction](https://taiko.xyz/docs/concepts/creating-taiko-blocks/anchor-transaction) to create a MXC L2 block.
- - IF any transaction in the list is invalid, the block is proven to be invalid.
-4. MXC is the default gas to pay L2 proposers and on the top of that they need to burn a certain amount of MXC to compete for proposing blocks to L1
\ No newline at end of file
+ - IF every transaction in the list is valid, an ordered subset of the list is created by skipping over transactions which have an invalid nonce or the sender has too little MXC balance to pay for the transaction. This ordered subset is used along with the [anchor transaction](https://taiko.xyz/docs/concepts/creating-taiko-blocks/anchor-transaction) to create a MXC L2 block.
+ - IF any transaction in the list is invalid, the block is proven to be invalid.
+4. MXC is the default gas to pay L2 proposers and on the top of that they need to burn a certain amount of MXC to compete for proposing blocks to L1
diff --git a/docs/Designs/Proving.md b/docs/Designs/Proving.md
index b4007a2..7527b73 100644
--- a/docs/Designs/Proving.md
+++ b/docs/Designs/Proving.md
@@ -1,23 +1,23 @@
---
-sidebar_position: 2
+sidebar_position: 3
---
# Proving MXC Blocks
-
## Zero-Knowledge Provers
-The purpose of proving blocks is to allow bridges to withdraw state out of the rollup.
+The purpose of proving blocks is to allow bridges to withdraw state out of the rollup.
-To rely on some state that happened inside of the rollup, a bridge will want a proof that everything was done correctly. On MXC zkEVM you can run a Supernode as a prover and prove blocks, permissionlessly.
+To rely on some state that happened inside of the rollup, a bridge will want a proof that everything was done correctly. On MXC zkEVM you can run a Supernode as a prover and prove blocks, permissionlessly.
-This means that you can examine the proposed blocks on the MXCzkL1 contract, and generate proofs for them. Currently, any prover can create proofs for proposed blocks. This means that the number of "fork choices" has no upper bound, because we don't know what is the correct state transition yet.
+This means that you can examine the proposed blocks on the MXCzkL1 contract, and generate proofs for them. Currently, any prover can create proofs for proposed blocks. This means that the number of "fork choices" has no upper bound, because we don't know what is the correct state transition yet.
Only first prover with a valid proof of the correct fork choice (state transition) will receive the reward of MXC.
## Zero-Knowledge States
There are three states that a block can be in on MXC zkEVM:
+
- Proposed
- Proved
- Verified
@@ -25,4 +25,3 @@ There are three states that a block can be in on MXC zkEVM:
For the visual learners here is a visualization of the three stages (proposed -> proved -> verified)
-
diff --git a/docs/Designs/Supernode.md b/docs/Designs/Supernode.md
index 5fa2aba..97ad1fe 100644
--- a/docs/Designs/Supernode.md
+++ b/docs/Designs/Supernode.md
@@ -1,5 +1,5 @@
---
-sidebar_position: 5
+sidebar_position: 6
---
# MXC Supernode (V2)
@@ -7,10 +7,10 @@ sidebar_position: 5
Previous documents published about MXC [SupernodeV1](https://www.mxc.org/supernode)
In the zkEVM SupernodeV2,there are two parts to a MXC Supernode, which are connected over the engine API:
+
- `mxc-geth`
- `mxc-client`
-
## MXC geth
The [mxc-geth](https://github.com/MXCzkEVM/) repo is a fork of [taiko-geth](https://github.com/taikoxyz/taiko-geth) with some changes according to MXprotocol, it serves as an IoT Web3 platform, which needs to be coupled to a LPWAN cluster mentioned in previous chapter, like L1/L2 ethereum execution engines, it will listen to new IoT transactions broadcasted in the IoT network, executes them in EVM, and holds the latest state and database of all current IoT data and submit proofs via Zero-Knowledge.
diff --git a/docs/Designs/XSD.md b/docs/Designs/XSD.md
index 433f26a..ffce71e 100644
--- a/docs/Designs/XSD.md
+++ b/docs/Designs/XSD.md
@@ -1,35 +1,31 @@
---
-sidebar_position: 6
+sidebar_position: 7
---
# MXC Stable Coin (V1)
-MXC will be the largest Layer-3 IoT solution on Arbitrum ecosystem, bringing tremendous real-world items to NFT world and data to the blockchain. Undoubtedly each real-world item and each piece of data has its own value, and this kind of value is not from pure financial speculations, the value comes from real economy that serves our food, sports, transportation every day.
+MXC will be the largest Layer-3 IoT solution on Arbitrum ecosystem, bringing tremendous real-world items to NFT world and data to the blockchain. Undoubtedly each real-world item and each piece of data has its own value, and this kind of value is not from pure financial speculations, the value comes from real economy that serves our food, sports, transportation every day.
MXC is going to leverage the real-world economy to build the first stable coin backed by items like Gin, Bike sensors, Nike shoes etc. Along with the tokens created on zkEVM like Ride token, Park token and MXC, BTC, the MXC stable coin has a basket ranging from NFT to tokens to back the stable coin from the real-world economy.
-
XSD, in conjunction with MXC and ISO projects, aims to empower individuals and companies to generate and circulate XSD within their unique economic systems, supporting their specific business requirements. The objective is to transform the existing financial landscape, where the majority of stable coins and fiat currencies rely on the backing of US treasury bonds. With a staggering 30 trillion USD in US treasury bonds and only 4 trillion in gold and other reserves held by the US Treasury and Federal Reserve, this initiative seeks to establish a more decentralized and diverse foundation for global financial systems.
-
-
As IoT [Swap](https://swap.mxc.com/) shows, the IoT tokens like Ride token would be the major applications that use MXC network and ISO projects to build their own data economy. These Ride and Park token can be swapped in MXC Swap conveniently, through XSD trading pair. XSD will be the first IoT stable coin that are backed by real-world assets and data values, meanwhile serving for the digital and real-world economy.
MXProtocol design and its ecosystem both are aimed for validating the XSD stable coin，which is pegged to US dollars at start in 1:2 manner. Along with the NFC, LoraWAN and Satellite technologies, users are able to verify and validate the value of XSD are backed by collateral like Gin 1689 NFTs, and MXC/DG/Ride tokens.
IoT NFTs need to reach a minimal IoT NFT transactions, in the initial roll-out is three transactions in order to become a collateral. This is to raise the attacking cost to enter the XSD mint basket.
-
NFTs and tokens are used as collateral to back the XSD, the XSD/USD conversion rate is to make sure the XSD can trade with USD from 1 XSD = 2 USD for the future market fluctuation. Normally the NFTs are issued by companies and manufacturers to let communities to burn XSD and get a collateral NFT, in the whole reserve of the MXC there are 20 percent of cryptocurrencies as collateral, the rest of 80% should be IoT NFTs that are backed by real-world assets.
The ratio of the 20/80 percent should be adjusted by MXC Reserve, namely MXC DAO in referendum : https://snapshot.org/#/mxcpop.eth
-The starting point 20/80 is to reduce the fluctuation of Sensor Token part and let the basket to fill with 80% real-world collectables that is not volatile at all. A referendum in MXC DAO can trigger the change of the ratio.
+The starting point 20/80 is to reduce the fluctuation of Sensor Token part and let the basket to fill with 80% real-world collectables that is not volatile at all. A referendum in MXC DAO can trigger the change of the ratio.
In the following example, it shows how XSD is backed:
| Collateral | Value USD | Quantity | Total USD | Percentage |
-|--------------|-----------|----------|-----------|------------|
+| ------------ | --------- | -------- | --------- | ---------- |
| Diamond NFT | 2700 | 10 | 27000 | 72% |
| Gin 1689 NFT | 100 | 30 | 3000 | 8% |
| MXC token | 1 | 2000 | 2000 | 5.3% |
@@ -47,15 +43,13 @@ Every time the XSD is mint will need to follow the most updated conversion rate
In this case, the users will try to redeem one Gin 1689 NFT to get 100USD worth of NFT, and also to get 25USD of any token, like 25USD MXC token. So the user needs to burn 250 XSD, in return he gets 1 Gin 1689 NFT and 25USD MXC. This case is assuming the interest rate is 0% from XSD mint to the borrower.
| Collateral redeemed | Value USD | Quantity | Total Burnt XSD | Percentage |
-|---------------------|-----------|----------|-----------|------------|
-| Gin 1689 NFT | 100 | 1 | 50 | 80% |
-| MXC token | 1 | 25 | 12.5 | 20% |
-| | | | 62.5 | 100% |
-
-
-
+| ------------------- | --------- | -------- | --------------- | ---------- |
+| Gin 1689 NFT | 100 | 1 | 50 | 80% |
+| MXC token | 1 | 25 | 12.5 | 20% |
+| | | | 62.5 | 100% |
## Insurance
+
The goal of XSD and MXC is to enable every person/company to create XSD and circulate in their own economy to support their business logic, eventually it is to change the current situation that all the stable coins and Fiat currencies are backed by US treasury bonds, while US treasury bonds are like 30 trillion USD and US treasury and Fed Reserve only got 4 trillion gold or other reserves.
We need to peg this world better with the assets created by people and used by people. Also we need to deal with systematic risks if the de-peg happens. Central banks proposes to print more money to solve the problem. MXC DAO proposes that we should add a 10% insurance on the top of the every XSD mint to deal with the systematic risks.
@@ -66,7 +60,7 @@ The insurance should be an option at the end of the minting process.
## XSD exchange rate with USD
-When the XSD economy is getting bigger and bigger, the MXC DAO should see the 1:2 exchange rate will fluctuate due to the demand of XSD is higher than USD and people lose trust in USD.
+When the XSD economy is getting bigger and bigger, the MXC DAO should see the 1:2 exchange rate will fluctuate due to the demand of XSD is higher than USD and people lose trust in USD.
This is due to the volatility of the Fed Reserve to create more balance sheet and run-off the balance sheet without any anchor, XSD holder should aim for a certain development that the unit price of the collateral like watch, shoes, wines are defined by the unit of a XSD and no longer will be a USD.
@@ -77,6 +71,7 @@ Every time the XSD is mint will need to follow the most updated conversion rate
:::
## Lending use cases
+
It is expected that people will borrow XSD and lend XSD to generate stable APY, there are a lot of similar lending protocols like AAVE will move to MXC zkEVM to enable XSD economy active.
## Use case of XSD
@@ -89,7 +84,7 @@ It is expected that people will borrow XSD and lend XSD to generate stable APY,
## XSD mint Implementation
-This chapter introduces XSD minting: a peer-to-peer perpetual lending protocol that supports Sensor token and IoT NFTs. XSD has no oracle dependencies and no expiries, allowing borrowing positions to remain open indefinitely until liquidated, with market-determined interest rates.
+This chapter introduces XSD minting: a peer-to-peer perpetual lending protocol that supports Sensor token and IoT NFTs. XSD has no oracle dependencies and no expiries, allowing borrowing positions to remain open indefinitely until liquidated, with market-determined interest rates.
XSD mint matches users who want to borrow against their real-world collateral with whatever lender is willing to offer the most competitive rate, using a sophisticated off-chain offer protocol.
@@ -147,25 +142,22 @@ So, instead of simply giving the collateral NFT and token to the XSD mint, the p
At the expiration time, if the borrower has not repaid the debt, a refinancing auction begins at 0%, with a steadily rising rate. Once the auction hits an interest rate at which XSD mint is interested in lending, the XSD mint can accept it by submitting their offer on-chain. The XSD mint pays the full repayment amount to itselves, calculated as of the moment the auction completes, and takes over the loan until the new expiration time (which could be calculated as the current expiration time plus some protocol-specified loan period), using the interest rate at which the auction resolved.
-
## Liquidation
It is possible that this Dutch auction may not be able to find a willing party to take, especially if the value of the collateral has dropped close to or below the value of the debt.
-Once the auction hits some defined max rate (like 1000%) without letting XSD mint to re-stepping in, the protocol infers that the position is insolvent or otherwise non-viable, and liquidates the borrower. The existing lender can then send a transaction to take possession of the collateral.
+Once the auction hits some defined max rate (like 1000%) without letting XSD mint to re-stepping in, the protocol infers that the position is insolvent or otherwise non-viable, and liquidates the borrower. The existing lender can then send a transaction to take possession of the collateral.
Also the insurance in this case should repay the difference amounts to the borrower if the liquidation is faield.
Except for MXC DAO referendum can trigger a liquidation event, borrower usually won't repay if the interest rate is 0% or even in some cases can be below 0%.
-
## Optimistic Auctions
In the majority of the cases, the XSD mint might be happy to continue the same loan at the same terms, and the borrower may too. We might even consider that the default scenario. In that case, it would be wasteful to run the auction.
Instead, we could design our protocol to optimistically renew the loan. At each expiration time, borrowers and lenders, by default, extend the expiration time by some predetermined loan period, with the same terms. The above-described auction would only occur if the lender seeks to terminate the loan.
-
## Continuous Loans
One issue with the above protocol is that during a loan period, if the price of the collateral falls dangerously close to the price of the repayment amount, there is no way to liquidate it until the expiration time.
@@ -180,12 +172,10 @@ A borrower can repay at any time. If a borrower wants to change the amount they
If a referendum in MXC DAO wants to get out of a certain XSD mint loan, they can trigger a refinancing auction, as discussed above. All timelines and deadlines during refinancing events can be defined relative to the time the refinancing was initiated.
-Alternatively, if the interest rate is adjusted by the XSD mint, the current lend can skip the auction by submitting the other offer to the vault to get out of their loan.
-
+Alternatively, if the interest rate is adjusted by the XSD mint, the current lend can skip the auction by submitting the other offer to the vault to get out of their loan.
## Governance Considerations
-
The protocol does not depend on governance for valuing collateral or setting acceptable loan-to-value ratios, thus reducing the need for extensive on-chain governance or centralized administrators. However, there may still be situations where adjustments to certain parameters could enhance the protocol's functionality. These parameters include:
Fees: Borrower and lender fees collected by the protocol.
diff --git a/docs/Tutorials/zkevm.md b/docs/Designs/zkevm.md
similarity index 100%
rename from docs/Tutorials/zkevm.md
rename to docs/Designs/zkevm.md
diff --git a/docs/Tutorials/Interact_with_IoT-Device.md b/docs/Tutorials/Interact_with_IoT-Device.md
index 3084085..2f4c8ab 100644
--- a/docs/Tutorials/Interact_with_IoT-Device.md
+++ b/docs/Tutorials/Interact_with_IoT-Device.md
@@ -5,6 +5,14 @@ sidebar_position: 13
This demonstration showcases the ability to control a physical device using Moonchain. It highlights how a blockchain transaction on Moonchain can remotely turn an LED on or off. Through this process, you will see the seamless integration of blockchain technology with real-world hardware, emphasizing the potential for secure, decentralized control in various applications.
+English version:
+
+
+
+German version:
+
+
+
## Moonchain Info
Contract proposals: [https://github.com/MXCzkEVM/MEPs](https://github.com/MXCzkEVM/MEPs)
@@ -21,7 +29,6 @@ Private key:
318dee0c207c20f4767e342a52e876b816379334a53277773c783b0e9348d368
-
## Change the X2E firmware
If your X2E board is running another firmware, please follow the procedures below to change the firmware for this demonstration.
@@ -29,10 +36,12 @@ If your X2E board is running another firmware, please follow the procedures belo
Firmware Repository: [https://github.com/MXCzkEVM/Moonchain-Control-X2E](https://github.com/MXCzkEVM/Moonchain-Control-X2E)
1. Download the mobile APP tool (Nordic DFU) for firmware update.
+
- [Google Play Store](https://play.google.com/store/apps/details?id=no.nordicsemi.android.dfu&hl=en&gl=US)
- [Apple App Store](https://apps.apple.com/tt/app/nrf-device-firmware-update/id1624454660) (require iOS 16)
2. Copy the firmware binary file `demo_controls_dfu_ism2400.zip` to your mobile phone.
+
- (Important: Place the file in the download folder, otherwise it may not be recognized correctly)
3. Start the DFU App and select the firmware binary file.
@@ -65,7 +74,6 @@ Find a temporary email service provider to get the email address for receiving t
Check the device profile (from MEP803) that we will be using. It needs to match the firmware of the X2E board. We will be using an existing ISM2400 profile, with the index set to 3.
-
```
cast call 0xBFc77Ee5959699eC4171891b625D6EccdC9e00cD "deviceProfileList(uint256) (uint256,string,address,string,bool,uint256)" 3 --rpc-url https://geneva-rpc.moonchain.com --private-key 318dee0c207c20f4767e342a52e876b816379334a53277773c783b0e9348d368
```
@@ -81,8 +89,6 @@ true
100000000000000000
```
-
-
Check the unit price of a PID from MEP802.
```
@@ -91,8 +97,6 @@ cast call 0x28479D68cD3ef5661BDB7505EFD1712D5D0951F6 "pidUnitPrice() (uint256)"
The response will be `123450000000000000000` wei, means 123.45 MXC.
-
-
Please replace the email address with your own and send the following command to purchase one PID via MEP802.
```
@@ -107,10 +111,6 @@ Please read the PID `K2ILSDXUOO3O4EEIWZDDW6SL` from the attached file and use it
-
-
-
-
## Setup the X2E board.
Connect the X2E board to your computer using a USB Type-C cable. Next, launch a serial terminal program like `minicom` on Linux or `PuTTY` on Windows, and establish a connection with the X2E board. Use the serial settings `115200 8N1`.
@@ -123,7 +123,7 @@ Then send a "AT" command to test the connection. If the connection is correct, t
-Send the following command at the serial terminal program to change the PID of the X2E board. *Replace the PID to the one got from previous steps.* You will get a OK if success.
+Send the following command at the serial terminal program to change the PID of the X2E board. _Replace the PID to the one got from previous steps._ You will get a OK if success.
```
AT+CQRCODE={"PID":"K2ILSDXUOO3O4EEIWZDDW6SL","B":"MatchX","M":"X2E","V":"1.3"}
@@ -145,8 +145,6 @@ If this doesn't happen after 6 minutes, please check the status of your NEO mine
After that, your X2E board is connected and able to accept data from the Moonchain.
-
-
## Mint the sensor NFT for the X2E board
Check the price for minting a sensor NFT.
@@ -163,8 +161,6 @@ The response will similar as below. The first line is the price. 987650000000000
true
```
-
-
Mint the NFT by replacing `0xf6d4bd...` with the pidZkevmHash you received earlier.
```
@@ -173,18 +169,12 @@ cast send 0x28479D68cD3ef5661BDB7505EFD1712D5D0951F6 "mintSensorNFT(uint256,uint
After Sensor NFT minted, you are ready to send data to the X2E board via Moonchain.
-
-
To repeat the minting process, you must first burn the Sensor NFT.
```
cast send 0x28479D68cD3ef5661BDB7505EFD1712D5D0951F6 "burnSensorNFT(uint256)" 0xf6d4bda9e25797a1423a41c485bfaa8e03930f0dbdf2d2b324d79fa71d8c9108 --rpc-url https://geneva-rpc.moonchain.com --private-key 318dee0c207c20f4767e342a52e876b816379334a53277773c783b0e9348d368
```
-
-
-
-
## Controlling via Moonchain
The controlled pin output has three modes: the first mode sets the output to always low, the second mode sets it to always high, and the third mode toggles the pin, causing the LED to blink.
@@ -193,8 +183,6 @@ Please replace `0xf6d4bd...` with the pidZkevmHash you received earlier in the e
The controlled pin should be changed within 2 minutes after the transaction is completed.
-
-
Set controlled to low (Turn off LED):
```
@@ -212,10 +200,3 @@ Set controlled to cycling (Blinking the LED):
```
cast send 0x28479D68cD3ef5661BDB7505EFD1712D5D0951F6 "enqueueDownlink(uint256,string,uint8,uint8)" 0xf6d4bda9e25797a1423a41c485bfaa8e03930f0dbdf2d2b324d79fa71d8c9108 "QhMC" 1 0 --rpc-url https://geneva-rpc.moonchain.com --private-key 318dee0c207c20f4767e342a52e876b816379334a53277773c783b0e9348d368
```
-
-
-
-
-
-
-