Connect with us

News

Ecco come è stato sviluppato un sistema di posta elettronica decentralizzato sulla blockchain

Chain Feed Staff

Published

on

Search icon

La tecnologia blockchain non supporta solo la criptovaluta, ha una vasta gamma di casi d’uso nel mondo reale. Qui, stiamo parlando di un software di posta elettronica decentralizzato basato sulla tecnologia blockchain che è unico per il tradizionale sistema di posta elettronica centralizzato basato su server.

Inoltre, offre maggiore sicurezza, privacy e affidabilità.

Le piattaforme di posta elettronica basate su server centralizzati sono a rischio di problemi di errore a punto singolo. Gli aggressori utilizzano tecniche diverse come attacchi Brute Force e hack del protocollo IMAP o dei server di posta elettronica per ottenere l’accesso non autorizzato agli account degli utenti. Ciò suggerisce che questa generazione moderna richiede una soluzione immediata per controllare i propri dati e la propria privacy con una piattaforma sicura per inviare o ricevere e-mail.

Tenendo presente la decentralizzazione e sfruttando le capacità uniche della blockchain, questo articolo ti insegnerà a sviluppare un software di posta decentralizzato.

Qui, costruiremo un software di posta decentralizzato su Testnet di Rootstock che può essere infine distribuito anche alla mainnet di Rootstock. Il nostro software sarà in grado di inviare o ricevere e-mail, inviare file come allegati, rispondere alle e-mail ed eliminare messaggi. Quindi, sarà interessante. Cominciamo creando la directory del progetto, ad esempio “decentralized-mail”.

📥Requisiti

Prima di iniziare il processo di sviluppo, è necessario avere un’idea delle funzionalità del codice dei linguaggi di programmazione e degli strumenti menzionati.

  • Idee sulle funzionalità del codice di JavaScript, Solidity e CSS.

  • Node.js: Scarica e installa da NodeJS.org è un’organizzazione senza scopo di lucro..

  • Tartufo: Per implementare contratti intelligenti.

    npm install -g truffle
    
  • SDK per la pignatta: Per interagire con Pinata

    npm install @pinata/sdk
    
  • Assi: Per effettuare richieste HTTP a Pinata.

    npm install axios
    

📥Struttura della directory del progetto

Si prega di notare prima la directory del progetto. Creare le cartelle e i file all’interno delle cartelle passo dopo passo come segue.

Figura 1: Directory del progettoFigura 1: Directory del progetto

📥Sviluppa contratti intelligenti

Dobbiamo creare un file di contratto Solidity. Crea DecentralizedMail.sol nella directory contracts/DecentralizedMail.sol come segue:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract DecentralizedMail {
    struct Message {
        address sender;
        address receiver;
        string content; // IPFS hash or plain text
        string imageHash; // IPFS hash of the image
        uint256 timestamp;
        bool isDeleted; // Flag to mark message as deleted
    }

    Message[] public messages;
    mapping(address => uint256[]) public userMessages;

    event MessageSent(address indexed sender, address indexed receiver, uint256 messageId);
    event MessageDeleted(address indexed user, uint256 messageId);

    function sendMessage(address _receiver, string memory _content, string memory _imageHash) public {
        uint256 messageId = messages.length;
        messages.push(Message({
            sender: msg.sender,
            receiver: _receiver,
            content: _content,
            imageHash: _imageHash,
            timestamp: block.timestamp,
            isDeleted: false
        }));
        userMessages[_receiver].push(messageId);
        userMessages[msg.sender].push(messageId); // Add message to sender's message list
        emit MessageSent(msg.sender, _receiver, messageId);
    }

    function getMessages() public view returns (Message[] memory) {
        return messages;
    }

    function getUserMessages(address _user) public view returns (uint256[] memory) {
        return userMessages[_user];
    }

    function getMessageById(uint256 messageId) public view returns (Message memory) {
        require(messageId < messages.length, "Message does not exist");
        return messages[messageId];
    }

    function deleteMessage(uint256 messageId) public {
        require(messageId < messages.length, "Message does not exist");
        Message storage message = messages[messageId];
        require(message.receiver == msg.sender || message.sender == msg.sender, "Not authorized to delete this message");
        message.isDeleted = true;
        emit MessageDeleted(msg.sender, messageId);
    }

    function getUserInbox(address _user) public view returns (Message[] memory) {
        uint256[] memory messageIds = userMessages[_user];
        Message[] memory inbox = new Message[](messageIds.length);
        uint256 counter = 0;

        for (uint256 i = 0; i < messageIds.length; i++) {
            Message storage message = messages[messageIds[i]];
            if (!message.isDeleted) {
                inbox[counter] = message;
                counter++;
            }
        }

        // Resize the array to fit the number of non-deleted messages
        Message[] memory resizedInbox = new Message[](counter);
        for (uint256 j = 0; j < counter; j++) {
            resizedInbox[j] = inbox[j];
        }

        return resizedInbox;
    }
}

Il nostro contratto fornisce una piattaforma decentralizzata per gli utenti per inviare ( sendMessage viene utilizzata la funzione), recupera (getMessages viene utilizzata la funzione) ed elimina i messaggi (deleteMessage funzione viene utilizzata) in modo sicuro utilizzando la tecnologia blockchain Rootstock. I messaggi vengono archiviati on-chain con dettagli quali mittente, destinatario, contenuto, hash dell’immagine, timestamp e stato di eliminazione.

📥Crea script di migrazione

Abbiamo bisogno di uno script di migrazione per semplificare il ciclo di vita dello sviluppo dello smart contract. Il suo ruolo principale nel nostro progetto è automatizzare e gestire il processo di distribuzione. Crea uno script di migrazione denominato 1_deploy_contracts.js nella directory radice come migrations/1_deploy_contracts.js come segue:

const DecentralizedMail = artifacts.require("DecentralizedMail");

module.exports = function(deployer) {
    deployer.deploy(DecentralizedMail);
};

📥Configura Truffle

Un file di configurazione Truffle è essenziale per definire come e dove verrà distribuito il nostro contratto intelligente.

Per prima cosa, installa la dipendenza usando npm:

npm install @truffle/hdwallet-provider

È progettato per specificare le impostazioni di rete, le versioni del compilatore e altri parametri di distribuzione come segue:

const HDWalletProvider = require('@truffle/hdwallet-provider');
require('dotenv').config();

module.exports = {
    networks: {
        development: {
            host: "localhost",
            port: 8545,
            network_id: "*" // Match any network id
        },
        testnet: { // Renamed from rskTestnet to testnet
            provider: () => new HDWalletProvider(process.env.MNEMONIC, 'https://public-node.testnet.rsk.co'),
            network_id: 31, // RSK Testnet network id
            gas: 5500000, // Gas limit (adjust if necessary)
            gasPrice: 1000000000, // Gas price in wei (1 gwei)
            networkCheckTimeout: 10000 // Timeout for network checks
        }
    },
    compilers: {
        solc: {
            version: "0.8.0"
        }
    }
};

Questa configurazione imposta gli ambienti di distribuzione e le opzioni del compilatore. Garantisce che i contratti siano distribuiti e compilati correttamente per le reti di sviluppo e test.

Nota: creare .env file nella directory root. Ora, crei il file con i seguenti codici e li aggiorni in seguito.

Devi mettere il tuo .env file nella directory principale del progetto come .env.example file come mostrato in Figure 1.

MNEMONIC=your_mnemonic_phrase_here //You need to add your wallet's 12 words mnemonic phrase here
REACT_APP_PINATA_API_KEY=your_pinata_api_key
REACT_APP_PINATA_SECRET_KEY=your_pinata_secret_key
REACT_APP_CONTRACT_ADDRESS=your_rsk_testnet_contract_address

Per favore ricordatelo fare un passo ** perché aggiornerai questo codice in seguito.

📥Imposta IPFS con Pinata

La nostra app di posta supporta anche le funzionalità di condivisione file tramite gli allegati. Quindi, stiamo utilizzando Caricare files funzionalità per IPFS tramite Pinata. Per prima cosa, crea l’account Pinata gratuito Qui.

Crea un file JavaScript per consentire il caricamento dei file nella directory scripts/pinata-upload.js come segue:

const axios = require('axios');
const FormData = require('form-data');
require('dotenv').config();

const API_KEY = process.env.PINATA_API_KEY;
const SECRET_KEY = process.env.PINATA_SECRET_KEY;

async function uploadToPinata(content) {
    const form = new FormData();
    form.append('file', content);

    try {
        const response = await axios.post('https://api.pinata.cloud/pinning/pinFileToIPFS', form, {
            headers: {
                ...form.getHeaders(),
                'pinata_api_key': API_KEY,
                'pinata_secret_api_key': SECRET_KEY,
            },
        });

        return response.data.IpfsHash;
    } catch (error) {
        console.error('Error uploading to Pinata:', error);
        throw error;
    }
}

// Example usage
const fs = require('fs');
const filePath = './example.txt'; // Replace with your file path
const fileContent = fs.createReadStream(filePath);

uploadToPinata(fileContent)
    .then(cid => console.log('File uploaded to IPFS with CID:', cid))
    .catch(err => console.error(err));

Per aggiornare il file, hai bisogno della chiave API e della chiave segreta di Pinata. .env archiviare a Fare un passo** come detto prima. Vai alla tua Piñata Dashboard>Chiavi API>Nuova chiave, e crea la tua nuova chiave API di amministrazione (seleziona la casella Amministratore opzione). Salva le chiavi API e le chiavi segrete in un posto sicuro.

📥Crea un’interfaccia front-end

È un passaggio cruciale. Il nostro front-end è costituito da tutte le funzionalità di base e dai codici per far funzionare le nostre app React sulla testnet Rootstock. Per semplificare il processo di sviluppo del front-end, ho già caricato i codici su GitHub. Puoi scaricarli da QuiInoltre, i codici sono lunghi e il nostro tutorial sarà già lungo, verrai guidato passo dopo passo a scaricare i file corretti da GitHub.

Imposta il progetto React

Apri il terminale dalla directory del tuo progetto e inserisci i seguenti comandi.

npx create-react-app mail-dapp
cd mail-dapp
npm install web3 @pinata/sdk

Crea componenti React

Nel tuo src cartella, creane un’altra components cartella e aggiungere il Upload.js file scaricando da Guida in linea.

Componente principale dell’app

Di nuovo, carica il file App.js in src/components/App.js directory scaricando il file da Guida in linea.

Configurare il punto di ingresso di React

In src cartella, caricare index.js file da Guida in linea.

Passiamo ora in rassegna gli altri componenti di sviluppo che supportano il processo di invio e ricezione di e-mail tramite il sistema di posta decentralizzato sulla testnet Rootstock.

Assicurati di scaricare i file SendMessage.js , Inbox.js, web3.jsE index.css dal Repository GitHub, e posizionarli nelle rispettive directory come mostrato nella directory del progetto Figura 1.

📥Test e distribuzione

Stiamo per testare e distribuire il nostro contratto su RSK Testnet usando Truffle. Seguite le istruzioni passo dopo passo.

Compilare il contratto

Eseguire il seguente comando nel terminale.

truffle compile

Se tutto è andato correttamente, nel terminale verranno visualizzati i seguenti messaggi.

Figura 2: Compilazione del contratto tramite TruffleFigura 2: Compilazione del contratto tramite Truffle

Migra (distribuisci) i tuoi contratti

Quindi, eseguire il seguente comando per distribuire il contratto:

truffle migrate --network testnet

Vedrai qualcosa di simile con l’indirizzo del contratto.

Figura 3: Output del terminale dopo la migrazione del contratto riuscitaFigura 3: Output del terminale dopo la migrazione del contratto riuscita

Si prega di copiare l’indirizzo del contratto e aggiornarlo .env archiviare Fare un passo ** sostituendo your_rsk_testnet_contract_address dal tuo indirizzo di contratto effettivo e aggiorna il file. Nota inoltre che, dopo una migrazione del contratto riuscita, troverai il DecentralizedMail.json archiviare \decentralized-mail\build directory. Copia il file JSON e incollalo in decentralized-mail/src/utils/

📥Crea l’app React

Assicurati di aver aggiornato .env file con tutti i dettagli corretti.

Eseguire il seguente comando nel terminale.

npm run build

Dopodiché, installa l’estensione MetaMask sul tuo browser e cambia la testnet RSK aggiungendo i seguenti dettagli:

Vai a Seleziona Rete>Aggiungi rete>RPC personalizzato, e poi inserisci le seguenti informazioni.

  • Nome della rete RSK Testnet
  • Nuovo URL RPC https://public-node.testnet.rsk.co
  • ChainID (facoltativo) 31
  • Simbolo (facoltativo) tRBTC

Ora esegui il seguente comando nel terminale.

npm start

Dovresti essere reindirizzato al browser. L’app React invocherà MetaMask. Approva la chiamata. L’interfaccia principale dovrebbe apparire come segue. Prova a inviare un messaggio a un indirizzo, ma tieni presente che hai un po’ di tRBTC nel tuo portafoglio per coprire il gas nella testnet RSK. Puoi ottenere tRBTC gratis da Rubinetto RSK.

Figura 4: Interfaccia principale del software di posta decentralizzata. Il front-end comunica con la rete RSK tramite MetaMask Figura 4: Interfaccia principale del software di posta decentralizzata. Il front-end comunica con la rete RSK tramite MetaMask

Puoi scrivere i testi e allegare file utilizzando Scegli il file opzione. Ho caricato una foto di Nikola Tesla. Assicurati di confermare la chiamata di MetaMask dopo aver inviato l’email all’indirizzo del destinatario. Attendi che la transazione venga confermata dalla blockchain. Una volta completato il processo, vedrai un messaggio di notifica inviato.

Controlliamo se l’indirizzo del destinatario ha il messaggio inviato nella posta in arrivo oppure no.

Figura 5: Il destinatario ha ricevuto correttamente un messaggio con file allegati nella testnet RSKFigura 5: Il destinatario ha ricevuto correttamente un messaggio con file allegati nella testnet RSK

Perfetto! Puoi vedere il messaggio inviato con il file allegato di Nikola Tesla. Puoi rispondere alla posta in arrivo o anche eliminare la posta in arrivo. Una volta che rispondi al messaggio, apparirà nella sezione posta in arrivo del mittente originale.

Figura 6: Test del "Rispondere" caratteristica, è apparsa una casella per digitare il testoFigura 6: Test del "Rispondere" caratteristica, è apparsa una casella per digitare il testo

Dopo aver risposto al messaggio, questo viene visualizzato nella posta in arrivo.

Figura 7: Nella posta in arrivo è apparso un messaggio di risposta che indica che l'applicazione funziona perfettamenteFigura 7: Nella posta in arrivo è apparso un messaggio di risposta che indica che l'applicazione funziona perfettamente

Vediamo che ne dici della funzionalità di eliminazione dei messaggi. Una volta cliccato sull’icona di eliminazione, l’app React richiama MetaMask per confermare la chiamata. Una volta completata la transazione, verrà contrassegnata e scomparirà dalla posta in arrivo.

Figura 8: La funzione di eliminazione del sistema di posta funziona poiché il messaggio è scomparso dalla posta in arrivo dopo la transazione confermataFigura 8: La funzione di eliminazione del sistema di posta funziona poiché il messaggio è scomparso dalla posta in arrivo dopo la transazione confermata

In questo modo, abbiamo sviluppato con successo un software di posta decentralizzata basato su blockchain sulla testnet RSK, che può essere distribuito anche sulla mainnet RSK semplicemente modificando i codici.

Si prega di notare che questo è il tutorial per sviluppare una piattaforma di messaggistica decentralizzata con le funzionalità di base. La sicurezza è stata la priorità sin dall’inizio, ma vi avverto di controllare tutto a vostro rischio e pericolo se vi state affrettando a sviluppare il vostro software pronto per la produzione.

Per il codice dettagliato, fare riferimento al repository GitHub: Posta decentralizzata GitHub.

📥Problemi comuni e soluzioni

1.EIP-1559 non supportato

Errore: Valore non valido specificato “Eip1559NotSupportedError“.

Errore: La rete non supporta eip-1559.

Soluzione: Assicurati che il gasPrice è specificato nelle opzioni di transazione. Dovresti anche aggiornare il codice frontend per gestire correttamente i prezzi del gas.

  1. Metamask non invocato

Dovresti installare l’estensione MetaMask nel tuo browser e configurare la testnet RSK nella configurazione di rete del tuo Wallet. Esamina attentamente il codice che window.ethereum.enable() viene utilizzato correttamente per richiedere a Metamask l’accesso all’account.

  1. Messaggi non visualizzati

Verifica che i messaggi siano correttamente inviati alla posta in arrivo del destinatario. In caso contrario, controlla la logica dello smart contract per l’archiviazione e il recupero dei messaggi.

Conclusione

Questo tutorial ti aiuta a creare una piattaforma di messaggistica decentralizzata basata su blockchain con le caratteristiche e le funzionalità di base. Con questo software di messaggistica, puoi inviare, ricevere, eliminare messaggi e rispondere ai messaggi tramite blockchain. Supporta anche le funzionalità di condivisione file tramite IPFS Pinata. Puoi modificare il codice per aggiungere più funzionalità con un’interfaccia utente accattivante per soddisfare le esigenze dei tuoi utenti.

La blockchain decentralizzata supporta il processo di invio e ricezione dei messaggi con una crittografia avanzata, il che significa che una piattaforma di scambio di posta elettronica decentralizzata potrebbe rivelarsi la scelta migliore in futuro.

Aiuta a proteggere i contenuti dalle note tattiche di phishing degli aggressori. Inoltre, questo tipo di piattaforma di messaggistica è protetta dal noto problema del singolo punto di errore e da altri attacchi dei criminali informatici perché l’indirizzo non è costituito dalle informazioni personali dell’utente.

Fuente

We are the editorial team of Chain Feed Staff, where seriousness meets clarity in cryptocurrency analysis. With a robust team of finance and blockchain technology experts, we are dedicated to meticulously exploring complex crypto markets with detailed assessments and an unbiased approach. Our mission is to democratize access to knowledge of emerging financial technologies, ensuring they are understandable and accessible to all. In every article on Chain Feed Staff, we strive to provide content that not only educates, but also empowers our readers, facilitating their integration into the financial digital age.

Continue Reading
Click to comment

Leave a Reply

Your email address will not be published. Required fields are marked *

Información básica sobre protección de datos Ver más

  • Responsable: Miguel Mamador.
  • Finalidad:  Moderar los comentarios.
  • Legitimación:  Por consentimiento del interesado.
  • Destinatarios y encargados de tratamiento:  No se ceden o comunican datos a terceros para prestar este servicio. El Titular ha contratado los servicios de alojamiento web a Banahosting que actúa como encargado de tratamiento.
  • Derechos: Acceder, rectificar y suprimir los datos.
  • Información Adicional: Puede consultar la información detallada en la Política de Privacidad.

News

An enhanced consensus algorithm for blockchain

Chain Feed Staff

Published

on

An enhanced consensus algorithm for blockchain

The introduction of the link and reputation evaluation concepts aims to improve the stability and security of the consensus mechanism, decrease the likelihood of malicious nodes joining the consensus, and increase the reliability of the selected consensus nodes.

The link model structure based on joint action

Through the LINK between nodes, all the LINK nodes engage in consistent activities during the operation of the consensus mechanism. The reputation evaluation mechanism evaluates the trustworthiness of nodes based on their historical activity status throughout the entire blockchain. The essence of LINK is to drive inactive nodes to participate in system activities through active nodes. During the stage of selecting leader nodes, nodes are selected through self-recommendation, and the reputation evaluation of candidate nodes and their LINK nodes must be qualified. The top 5 nodes of the total nodes are elected as leader nodes through voting, and the nodes in their LINK status are candidate nodes. In the event that the leader node goes down, the responsibility of the leader node is transferred to the nodes in its LINK through the view-change. The LINK connection algorithm used in this study is shown in Table 2, where LINKm is the linked group and LINKP is the percentage of linked nodes.

Table 2 LINK connection algorithm.

Node type

This paper presents a classification of nodes in a blockchain system based on their functionalities. The nodes are divided into three categories: leader nodes (LNs), follower nodes (FNs), and general nodes (Ns). The leader nodes (LNs) are responsible for producing blocks and are elected through voting by general nodes. The follower nodes (FNs) are nodes that are linked to leader nodes (LNs) through the LINK mechanism and are responsible for validating blocks. General nodes (N) have the ability to broadcast and disseminate information, participate in elections, and vote. The primary purpose of the LINK mechanism is to act in combination. When nodes are in the LINK, there is a distinction between the master and slave nodes, and there is a limit to the number of nodes in the LINK group (NP = {n1, nf1, nf2 ……,nfn}). As the largest proportion of nodes in the system, general nodes (N) have the right to vote and be elected. In contrast, leader nodes (LNs) and follower nodes (FNs) do not possess this right. This rule reduces the likelihood of a single node dominating the block. When the system needs to change its fundamental settings due to an increase in the number of nodes or transaction volume, a specific number of current leader nodes and candidate nodes need to vote for a reset. Subsequently, general nodes need to vote to confirm this. When both confirmations are successful, the new basic settings are used in the next cycle of the system process. This dual confirmation setting ensures the fairness of the blockchain to a considerable extent. It also ensures that the majority holds the ultimate decision-making power, thereby avoiding the phenomenon of a small number of nodes completely controlling the system.

After the completion of a governance cycle, the blockchain network will conduct a fresh election for the leader and follower nodes. As only general nodes possess the privilege to participate in the election process, the previous consortium of leader and follower nodes will lose their authorization. In the current cycle, they will solely retain broadcasting and receiving permissions for block information, while their corresponding incentives will also decrease. A diagram illustrating the node status can be found in Fig. 1.

Figure 1

Election method

The election method adopts the node self-nomination mode. If a node wants to participate in an election, it must form a node group with one master and three slaves. One master node group and three slave node groups are inferred based on experience in this paper; these groups can balance efficiency and security and are suitable for other project collaborations. The successfully elected node joins the leader node set, and its slave nodes enter the follower node set. Considering the network situation, the maximum threshold for producing a block is set to 1 s. If the block fails to be successfully generated within the specified time, it is regarded as a disconnected state, and its reputation score is deducted. The node is skipped, and in severe cases, a view transformation is performed, switching from the master node to the slave node and inheriting its leader’s rights in the next round of block generation. Although the nodes that become leaders are high-reputation nodes, they still have the possibility of misconduct. If a node engages in misconduct, its activity will be immediately stopped, its comprehensive reputation score will be lowered, it will be disqualified from participating in the next election, and its equity will be reduced by 30%. The election process is shown in Fig. 2.

Figure 2figure 2

Incentives and penalties

To balance the rewards between leader nodes and ordinary nodes and prevent a large income gap, two incentive/penalty methods will be employed. First, as the number of network nodes and transaction volume increase, more active nodes with significant stakes emerge. After a prolonged period of running the blockchain, there will inevitably be significant class distinctions, and ordinary nodes will not be able to win in the election without special circumstances. To address this issue, this paper proposes that rewards be reduced for nodes with stakes exceeding a certain threshold, with the reduction rate increasing linearly until it reaches zero. Second, in the event that a leader or follower node violates the consensus process, such as by producing a block out of order or being unresponsive for an extended period, penalties will be imposed. The violation handling process is illustrated in Fig. 3.

Figure 3figure 3

Violation handling process.

Comprehensive reputation evaluation and election mechanism based on historical transactions

This paper reveals that the core of the DPoS consensus mechanism is the election process. If a blockchain is to run stably for a long time, it is essential to consider a reasonable election method. This paper proposes a comprehensive reputation evaluation election mechanism based on historical records. The mechanism considers the performance indicators of nodes in three dimensions: production rate, tokens, and validity. Additionally, their historical records are considered, particularly whether or not the nodes have engaged in malicious behavior. For example, nodes that have ever been malicious will receive low scores during the election process unless their overall quality is exceptionally high and they have considerable support from other nodes. Only in this case can such a node be eligible for election or become a leader node. The comprehensive reputation score is the node’s self-evaluation score, and the committee size does not affect the computational complexity.

Moreover, the comprehensive reputation evaluation proposed in this paper not only is a threshold required for node election but also converts the evaluation into corresponding votes based on the number of voters. Therefore, the election is related not only to the benefits obtained by the node but also to its comprehensive evaluation and the number of voters. If two nodes receive the same vote, the node with a higher comprehensive reputation is given priority in the ranking. For example, in an election where node A and node B each receive 1000 votes, node A’s number of stake votes is 800, its comprehensive reputation score is 50, and only four nodes vote for it. Node B’s number of stake votes is 600, its comprehensive reputation score is 80, and it receives votes from five nodes. In this situation, if only one leader node position remains, B will be selected as the leader node. Displayed in descending order of priority as comprehensive credit rating, number of voters, and stake votes, this approach aims to solve the problem of node misconduct at its root by democratizing the process and subjecting leader nodes to constraints, thereby safeguarding the fundamental interests of the vast majority of nodes.

Comprehensive reputation evaluation

This paper argues that the election process of the DPoS consensus mechanism is too simplistic, as it considers only the number of election votes that a node receives. This approach fails to comprehensively reflect the node’s actual capabilities and does not consider the voters’ election preferences. As a result, nodes with a significant stake often win and become leader nodes. To address this issue, the comprehensive reputation evaluation score is normalized considering various attributes of the nodes. The scoring results are shown in Table 3.

Table 3 Comprehensive reputation evaluation.

Since some of the evaluation indicators in Table 3 are continuous while others are discrete, different normalization methods need to be employed to obtain corresponding scores for different indicators. The continuous indicators include the number of transactions/people, wealth balance, network latency, network jitter, and network bandwidth, while the discrete indicators include the number of violations, the number of successful elections, and the number of votes. The value range of the indicator “number of transactions/people” is (0,1), and the value range of the other indicators is (0, + ∞). The equation for calculating the “number of transactions/people” is set as shown in Eq. (1).

$$A_{1} = \left\{ {\begin{array}{*{20}l} {0,} \hfill & {{\text{G}} = 0} \hfill \\ {\frac{{\text{N}}}{{\text{G}}}*10,} \hfill & {{\text{G}} > 0} \hfill \\ \end{array} } \right.$$

(1)

where N represents the number of transactional nodes and G represents the number of transactions. It reflects the degree of connection between the node and other nodes. Generally, nodes that transact with many others are safer than those with a large number of transactions with only a few nodes. The limit value of each item, denoted by x, is determined based on the situation and falls within the specified range, as shown in Eq. (2). The wealth balance and network bandwidth indicators use the same function to set their respective values.

$${A}_{i}=20*\left(\frac{1}{1+{e}^{-{a}_{i}x}}-0.5\right)$$

(2)

where x indicates the value of this item and expresses the limit value.

In Eq. (3), x represents the limited value of this indicator. The lower the network latency and network jitter are, the higher the score will be.

The last indicators, which are the number of violations, the number of elections, and the number of votes, are discrete values and are assigned different scores according to their respective ranges. The scores corresponding to each count are shown in Table 4.

$$A_{3} = \left\{ {\begin{array}{*{20}l} {10*\cos \frac{\pi }{200}x,} \hfill & {0 \le x \le 100} \hfill \\ {0,} \hfill & {x > 100} \hfill \\ \end{array} } \right.$$

(3)

Table 4 Score conversion.

The reputation evaluation mechanism proposed in this paper comprehensively considers three aspects of nodes, wealth level, node performance, and stability, to calculate their scores. Moreover, the scores obtain the present data based on historical records. Each node is set as an M × N dimensional matrix, where M represents M times the reputation evaluation score and N represents N dimensions of reputation evaluation (M < = N), as shown in Eq. (4).

$${\text{N}} = \left( {\begin{array}{*{20}c} {a_{11} } & \cdots & {a_{1n} } \\ \vdots & \ddots & \vdots \\ {a_{m1} } & \cdots & {a_{mn} } \\ \end{array} } \right)$$

(4)

The comprehensive reputation rating is a combined concept related to three dimensions. The rating is set after rating each aspect of the node. The weight w and the matrix l are not fixed. They are also transformed into matrix states as the position of the node in the system changes. The result of the rating is set as the output using Eq. (5).

$$\text{T}=\text{lN}{w}^{T}=\left({l}_{1}\dots {\text{l}}_{\text{m}}\right)\left(\begin{array}{ccc}{a}_{11}& \cdots & {a}_{1n}\\ \vdots & \ddots & \vdots \\ {a}_{m1}& \cdots & {a}_{mn}\end{array}\right){\left({w}_{1}\dots {w}_{n}\right)}^{T}$$

(5)

Here, T represents the comprehensive reputation score, and l and w represent the correlation coefficient. Because l is a matrix of order 1*M, M is the number of times in historical records, and M <  = N is set, the number of dimensions of l is uncertain. Set the term l above to add up to 1, which is l1 + l2 + …… + ln = 1; w is also a one-dimensional matrix whose dimension is N*1, and its purpose is to act as a weight; within a certain period of time, w is a fixed matrix, and w will not change until the system changes the basic settings.

Assume that a node conducts its first comprehensive reputation rating, with no previous transaction volume, violations, elections or vote. The initial wealth of the node is 10, the latency is 50 ms, the jitter is 100 ms, and the network bandwidth is 100 M. According to the equation, the node’s comprehensive reputation rating is 41.55. This score is relatively good at the beginning and gradually increases as the patient participates in system activities continuously.

Voting calculation method

To ensure the security and stability of the blockchain system, this paper combines the comprehensive reputation score with voting and randomly sorts the blocks, as shown in Eqs. (36).

$$Z=\sum_{i=1}^{n}{X}_{i}+nT$$

(6)

where Z represents the final election score, Xi represents the voting rights earned by the node, n is the number of nodes that vote for this node, and T is the comprehensive reputation score.

The voting process is divided into stake votes and reputation votes. The more reputation scores and voters there are, the more total votes that are obtained. In the early stages of blockchain operation, nodes have relatively few stakes, so the impact of reputation votes is greater than that of equity votes. This is aimed at selecting the most suitable node as the leader node in the early stage. As an operation progresses, the role of equity votes becomes increasingly important, and corresponding mechanisms need to be established to regulate it. The election vote algorithm used in this paper is shown in Table 5.

Table 5 Election vote counting algorithm.

This paper argues that the election process utilized by the original DPoS consensus mechanism is overly simplistic, as it relies solely on the vote count to select the node that will oversee the entire blockchain. This approach cannot ensure the security and stability of the voting process, and if a malicious node behaves improperly during an election, it can pose a significant threat to the stability and security of the system as well as the safety of other nodes’ assets. Therefore, this paper proposes a different approach to the election process of the DPoS consensus mechanism by increasing the complexity of the process. We set up a threshold and optimized the vote-counting process to enhance the security and stability of the election. The specific performance of the proposed method was verified through experiments.

The election cycle in this paper can be customized, but it requires the agreement of the blockchain committee and general nodes. The election cycle includes four steps: node self-recommendation, calculating the comprehensive reputation score, voting, and replacing the new leader. Election is conducted only among general nodes without affecting the production or verification processes of leader nodes or follower nodes. Nodes start voting for preferred nodes. If they have no preference, they can use the LINK mechanism to collaborate with other nodes and gain additional rewards.

View changes

During the consensus process, conducting a large number of updates is not in line with the system’s interests, as the leader node (LN) and follower node (FN) on each node have already been established. Therefore, it is crucial to handle problematic nodes accurately when issues arise with either the LN or FN. For instance, when a node fails to perform its duties for an extended period or frequently fails to produce or verify blocks within the specified time range due to latency, the system will precisely handle them. For leader nodes, if they engage in malicious behavior such as producing blocks out of order, the behavior is recorded, and their identity as a leader node is downgraded to a follower node. The follower node inherits the leader node’s position, and the nature of their work is transformed as they swap their responsibilities of producing and verifying blocks with their original work. This type of behavior will not significantly affect the operation of the blockchain system. Instead of waiting until the end of the current committee round to punish malicious nodes, dynamic punishment is imposed on the nodes that affect the operation of the blockchain system to maintain system security. The view change operation is illustrated in Fig. 4.

Figure 4figure 4

In traditional PBFT, view changes are performed according to the view change protocol by changing the view number V to the next view number V + 1. During this process, nodes only receive view change messages and no other messages from other nodes. In this paper, the leader node group (LN) and follower node group (FN) are selected through an election of the LINK group. The node with LINKi[0] is added to the LN leader node group, while the other three LINK groups’ follower nodes join the FN follower node group since it is a configuration pattern of one master and three slaves. The view change in this paper requires only rearranging the node order within the LINK group to easily remove malicious nodes. Afterward, the change is broadcast to other committee nodes, and during the view transition, the LINK group does not receive block production or verification commands from the committee for stability reasons until the transition is completed.

Fuente

Continue Reading

News

The Hype Around Blockchain Mortgage Has Died Down, But This CEO Still Believes

Chain Feed Staff

Published

on

The Hype Around Blockchain Mortgage Has Died Down, But This CEO Still Believes

LiquidFi Founder Ian Ferreira Sees Huge Potential in Blockchain Despite Hype around technology is dead.

“Blockchain technology has been a buzzword for a long time, and it shouldn’t be,” Ferriera said. “It should be a technology that lives in the background, but it makes everything much more efficient, much more transparent, and ultimately it saves costs for everyone. That’s the goal.”

Before founding his firm, Ferriera was a portfolio manager at a hedge fund, a job that ended up revealing “interesting intricacies” related to the mortgage industry.

Being a mortgage trader opened Ferriera’s eyes to a lot of the operational and infrastructure problems that needed to be solved in the mortgage-backed securities industry, he said. That later led to the birth of LiquidFi.

“The point of what we do is to get raw data attached to a resource [a loan] on a blockchain so that it’s provable. You reduce that trust problem because you have the data, you have the document associated with that data,” said the LiquidFi CEO.

Ferriera spoke with National Mortgage News about the value of blockchain technology, why blockchain hype has fizzled out, and why it shouldn’t.



Fuente

Continue Reading

News

New bill pushes Department of Veterans Affairs to examine how blockchain can improve its work

Chain Feed Staff

Published

on

New bill pushes Department of Veterans Affairs to examine how blockchain can improve its work

The Department of Veterans Affairs would have to evaluate how blockchain technology could be used to improve benefits and services offered to veterans, according to a legislative proposal introduced Tuesday.

The bill, sponsored by Rep. Nancy Mace, R-S.C., would direct the VA to “conduct a comprehensive study of the feasibility, potential benefits, and risks associated with using distributed ledger technology in various programs and services.”

Distributed ledger technology, including blockchain, is used to protect and track information by storing data across multiple computers and keeping a record of its use.

According to the text of the legislation, which Mace’s office shared exclusively with Nextgov/FCW ahead of its publication, blockchain “could significantly improve benefits allocation, insurance program management, and recordkeeping within the Department of Veterans Affairs.”

“We need to bring the federal government into the 21st century,” Mace said in a statement. “This bill will open the door to research on improving outdated systems that fail our veterans because we owe it to them to use every tool at our disposal to improve their lives.”

Within one year of the law taking effect, the Department of Veterans Affairs will be required to submit a report to the House and Senate Veterans Affairs committees detailing its findings, as well as the benefits and risks identified in using the technology.

The mandatory review is expected to include information on how the department’s use of blockchain could improve the way benefits decisions are administered, improve the management and security of veterans’ personal data, streamline the insurance claims process, and “increase transparency and accountability in service delivery.”

The Department of Veterans Affairs has been studying the potential benefits of using distributed ledger technology, with the department emission a request for information in November 2021 seeking input from contractors on how blockchain could be leveraged, in part, to streamline its supply chains and “secure data sharing between institutions.”

The VA’s National Institute of Artificial Intelligence has also valued the use of blockchain, with three of the use cases tested during the 2021 AI tech sprint focused on examining its capabilities.

Mace previously introduced a May bill that would direct Customs and Border Protection to create a public blockchain platform to store and share data collected at U.S. borders.

Lawmakers also proposed additional measures that would push the Department of Veterans Affairs to consider adopting other modernized technologies to improve veteran services.

Rep. David Valadao, R-Calif., introduced legislation in June that would have directed the department to report to lawmakers on how it plans to expand the use of “certain automation tools” to process veterans’ claims. The House of Representatives Subcommittee on Disability Assistance and Memorial Affairs gave a favorable hearing on the congressman’s bill during a Markup of July 23.



Fuente

Continue Reading

News

California DMV Uses Blockchain to Fight Auto Title Fraud

Chain Feed Staff

Published

on

California DMV Uses Blockchain to Fight Auto Title Fraud

TDR’s Three Takeaways: California DMV Uses Blockchain to Fight Fraud

  1. California DMV uses blockchain technology to manage 42 million auto titles.
  2. The initiative aims to improve safety and reduce car title fraud.
  3. The immutable nature of blockchain ensures accurate and tamper-proof records.

The California Department of Motor Vehicles (DMV) is implementing blockchain technology to manage and secure 42 million auto titles. This innovative move aims to address and reduce the persistent problem of auto title fraud, a problem that costs consumers and the industry millions of dollars each year. By moving to a blockchain-based system, the DMV is taking advantage of the technology’s key feature: immutability.

Blockchain, a decentralized ledger technology, ensures that once a car title is registered, it cannot be altered or tampered with. This creates a highly secure and transparent system, significantly reducing the risk of fraudulent activity. Every transaction and update made to a car title is permanently recorded on the blockchain, providing a complete and immutable history of the vehicle’s ownership and status.

As first reported by Reuters, the DMV’s adoption of blockchain isn’t just about preventing fraud. It’s also aimed at streamlining the auto title process, making it more efficient and intuitive. Traditional auto title processing involves a lot of paperwork and manual verification, which can be time-consuming and prone to human error. Blockchain technology automates and digitizes this process, reducing the need for physical documents and minimizing the chances of errors.

Additionally, blockchain enables faster verification and transfer of car titles. For example, when a car is sold, the transfer of ownership can be done almost instantly on the blockchain, compared to days or even weeks in the conventional system. This speed and efficiency can benefit both the DMV and the vehicle owners.

The California DMV’s move is part of a broader trend of government agencies exploring blockchain technology to improve their services. By adopting this technology, the DMV is setting a precedent for other states and industries to follow, showcasing blockchain’s potential to improve safety and efficiency in public services.

Want to stay up to date on Cannabis, AI, Small Cap and Crypto? Subscribe to our Daily Baked in Newsletter!



Fuente

Continue Reading

Trending

Copyright © 2024 CHAINFEED.INFO. All rights reserved. This website provides educational content and highlights that investing involves risks. It is essential to conduct thorough research before investing and to be prepared to assume potential losses. Be sure to fully understand the risks involved before making investment decisions. Important: We do not provide financial or investment advice. All content is presented for educational purposes only.