Author

Topic: Parallel and Delay (Read 137 times)

legendary
Activity: 2870
Merit: 7490
Crypto Swap Exchange
November 07, 2023, 05:19:28 AM
#10
I am considering whether it would be possible to incorporate the functionality of smart contracts into the Lightning Network, leveraging the protocol of Multi-Party HTLC.

Taproot Assets and RGB Protocol pose some similarity with your idea. Have you checked those?
legendary
Activity: 1568
Merit: 6660
bitcoincleanup.com / bitmixlist.org
November 07, 2023, 01:59:04 AM
#9
It is recommended to place additional information into a single post instead of making consecutive posts.

Anyway -

As I have said in other places, it is not a good idea to allow such a protocol to store arbitrary data. It should only be used for storing instructions, and the smallest amount of data feasibly required to do the job.

Also, it should not have network or filesystem capability (so that malware does not become a problem), and MAYBE it should be in a form of a limited programming language like some Lisp dialect which can then be compiled into bytes.
newbie
Activity: 7
Merit: 0
November 07, 2023, 01:39:15 AM
#8
Code:
#include 
#include
#include
#include
#include
#include
#include

// Transaction class definition
class Transaction {
public:
    std::string user_id;
    std::string payload;

    Transaction(const std::string &user_id, const std::string &payload) : user_id(user_id), payload(payload) {}
};

// BufferLayer class definition
class BufferLayer {
private:
    std::queue requestQueue;
    std::unordered_map processedResults;
    std::mutex mtx;
    std::condition_variable cv;
    bool finished = false;

public:
    void addTransaction(const Transaction &transaction) {
        std::lock_guard lock(mtx);
        requestQueue.push(transaction);
        cv.notify_one();
    }

    void processTransactions() {
        std::unique_lock lock(mtx);
        while (!finished) {
            if (requestQueue.empty()) {
                cv.wait(lock);
            } else {
                Transaction transaction = requestQueue.front();
                requestQueue.pop();
                lock.unlock();
                std::string simulatedResult = simulateExecution(transaction);
                presentPreprocessedResult(transaction, simulatedResult);
                lock.lock();
            }
        }
    }

    void finishProcessing() {
        std::lock_guard lock(mtx);
        finished = true;
        cv.notify_all();
    }

    std::string getResultForUser(const std::string &user_id) {
        std::lock_guard lock(mtx);
        auto it = processedResults.find(user_id);
        if (it != processedResults.end()) {
            return it->second;
        }
        return "Result not found";
    }

private:
    std::string simulateExecution(const Transaction &transaction) {
        // Simulate execution logic
        return "Simulated Result for " + transaction.payload;
    }

    void presentPreprocessedResult(const Transaction &transaction, const std::string &simulatedResult) {
        // Present the preprocessed result logic
        processedResults[transaction.user_id] = simulatedResult;
    }
};

// BaseChain class definition
class BaseChain {
private:
    BufferLayer &bufferLayer;

public:
    BaseChain(BufferLayer &bufferLayer) : bufferLayer(bufferLayer) {}

    void receiveAndExecuteTransaction(const Transaction &transaction) {
        // Execute the transaction on the base chain
        std::string executedResult = "Executed Result for " + transaction.payload;
        syncWithBufferLayer(transaction, executedResult);
    }

private:
    void syncWithBufferLayer(const Transaction &transaction, const std::string &executedResult) {
        // Synchronize buffer layer logic
        // Assuming bufferLayer has a method to update the processed results
        bufferLayer.presentPreprocessedResult(transaction, executedResult);
    }
};

// Usage example
int main() {
    BufferLayer bufferLayer;

    // Start buffer layer processing thread
    std::thread bufferLayerThread(&BufferLayer::processTransactions, &bufferLayer);

    // Create a BaseChain object with reference to BufferLayer
    BaseChain baseChain(bufferLayer);

    // Create a transaction
    Transaction newTransaction("user123", "data");

    // Add transaction to buffer layer
    bufferLayer.addTransaction(newTransaction);

    // Simulate base chain receiving and executing the transaction
    baseChain.receiveAndExecuteTransaction(newTransaction);

    // Finish processing in the buffer layer
    bufferLayer.finishProcessing();

    // Wait for buffer layer thread to complete
    bufferLayerThread.join();

    // Retrieve the result
    std::string result = bufferLayer.getResultForUser("user123");
    std::cout << result << std::endl;

    return 0;
}
newbie
Activity: 7
Merit: 0
November 07, 2023, 01:32:25 AM
#7
Brain-computer interfaces and real-time statuses of aircraft in the future world actually require blockchain technology. Otherwise, attacks like the ghost ship in Mission Impossible could very likely occur. However, achieving these almost relies on millisecond-level delays and the parallel processing capability of accommodating 1 billion users. A few days ago, I designed a small program using C++, which I call the 'buffer layer.' It displays the results of legally signed transactions on a page in advance, avoiding the 10 to 30-minute wait for the final block results. This process only takes 5-10ms, and it can present the altitude, speed, and direction of all aircraft simultaneously on a dashboard.

As I mentioned earlier regarding the buffer layer, when multiple users submit requests, the results of the simulated execution are presented on the chain in advance. This allows more protocols to achieve instant communication through this method. Currently, I am developing this part.
newbie
Activity: 7
Merit: 0
October 24, 2023, 06:24:52 AM
#6
Perhaps the node in Melbourne doesn't care that I ate a pizza for 10 US dollars in Seattle. Fast settlement on a small scale is needed. For the precious blockchain, it only needs to record whether the settlement has occurred and whether it has been tampered with. It doesn’t really need to verify and execute every single transaction. This is a load-balancing approach. Therefore, I want to use HTLC (Hash Time Locked Contracts) to build some tools.
newbie
Activity: 7
Merit: 0
October 24, 2023, 05:15:43 AM
#5
After two years of research, I believe that the biggest issues with blockchain currently are the capability of parallel processing and the delay in confirming results. I am considering whether it would be possible to incorporate the functionality of smart contracts into the Lightning Network, leveraging the protocol of Multi-Party HTLC. Here, smart contracts resemble communication rules available for multi-party participation, allowing all dApps to process independently and parallelly. The underlying base chain would no longer allow users to submit transactions independently, serving only as the final settlement layer. Does anyone have any suggestions or thoughts on this approach?

Lightning Network is in enough trouble without it and you want to bring in more.

Delay in propagation through out the current network  is small enough to have any noticeable effect on building bitcoin blockchain  thus there is no need in the settlement layer to correct the issue, IMXO.

Thank you for your reminder. The attacks targeting the Lightning Network mainly occur between multiple channels and during the routing process, such as the lightning replacement cycling attack you mentioned. I am merely borrowing this design concept to build a new system, not directly copying the Lightning Network. I am trying to solve the trust issue using Trustless channels and Asymmetric revocable commitments, which is also what I believe to be the most appealing advantage of the Lightning Network: simplifying consensus through cryptography.

Meanwhile, the delay I referred to is the time from submitting data to the blockchain to when the newly generated block includes this transaction. This time is unstable and often requires tens of minutes, not the propagation delay between nodes.
hero member
Activity: 714
Merit: 1298
October 24, 2023, 03:59:13 AM
#4
After two years of research, I believe that the biggest issues with blockchain currently are the capability of parallel processing and the delay in confirming results. I am considering whether it would be possible to incorporate the functionality of smart contracts into the Lightning Network, leveraging the protocol of Multi-Party HTLC. Here, smart contracts resemble communication rules available for multi-party participation, allowing all dApps to process independently and parallelly. The underlying base chain would no longer allow users to submit transactions independently, serving only as the final settlement layer. Does anyone have any suggestions or thoughts on this approach?

Lightning Network is in enough trouble without it and you want to bring in more.

Delay in propagation through out the current network  is small enough to have any noticeable effect on building bitcoin blockchain  thus there is no need in the settlement layer to correct the issue, IMXO.
newbie
Activity: 7
Merit: 0
October 24, 2023, 02:06:47 AM
#3
To address the issue of latency, I further categorized the transactions. Actually, in most dApps, the interactions can be divided into two types (inspired by Linux): one is where an actor A writes data into the blockchain, which I refer to as ECHO. This doesn't involve interactions with other states of the blockchain, such as writing a sentence into a block. The other type is where actor A interacts with multiple states of the blockchain, which I call VIM, like on Uniswap, where a transaction leads to changes in multiple data points such as price, the number of tokens in the pool, and staker benefits. When both types of transactions are legitimate, ECHO can be directly accepted after legal verification, while VIM, which is concerned about the transaction order, can invoke the buffer layer for acceleration.
newbie
Activity: 7
Merit: 0
October 24, 2023, 01:49:49 AM
#2
Brain-computer interfaces and real-time statuses of aircraft in the future world actually require blockchain technology. Otherwise, attacks like the ghost ship in Mission Impossible could very likely occur. However, achieving these almost relies on millisecond-level delays and the parallel processing capability of accommodating 1 billion users. A few days ago, I designed a small program using C++, which I call the 'buffer layer.' It displays the results of legally signed transactions on a page in advance, avoiding the 10 to 30-minute wait for the final block results. This process only takes 5-10ms, and it can present the altitude, speed, and direction of all aircraft simultaneously on a dashboard.
newbie
Activity: 7
Merit: 0
October 24, 2023, 01:42:03 AM
#1
After two years of research, I believe that the biggest issues with blockchain currently are the capability of parallel processing and the delay in confirming results. I am considering whether it would be possible to incorporate the functionality of smart contracts into the Lightning Network, leveraging the protocol of Multi-Party HTLC. Here, smart contracts resemble communication rules available for multi-party participation, allowing all dApps to process independently and parallelly. The underlying base chain would no longer allow users to submit transactions independently, serving only as the final settlement layer. Does anyone have any suggestions or thoughts on this approach?
Jump to: