
## Introduction

Proximal policy optimization (PPO) is an algorithm that aims to improve the stability of training by avoiding overly large policy updates. It is a popular and effective method used for training [ reinforcement learning]() models in complex environments. To achieve this, PPO uses a ratio that indicates the difference between the current policy and the old policy and clips this ratio within a specific range, ensuring that the policy updates are not too large and the training process is more stable.

## How does PPO work?

PPO uses the gradient ascent method to search for the optimal policy, but it applies constraints on policy changes by limiting the distance (clipping) between the old policy and the new policy. This helps control the policy update process to avoid excessive changes while ensuring stability and effectiveness in learning.

There are two approaches to accomplish this:

- _TRPO (Trust Region Policy Optimization)_ is complex to implement and computationally expensive. It uses outer KL-divergence constraints on the objective function to limit policy updates.
- _PPO's Clipped Surrogate Objective_ substitutes the KL-divergence constraints with its own clipped objective function.

## How to apply PPO for training large language models?

Large language models are trained with billions of parameters and produce impressive results. However, during actual operation, these models may introduce errors and inaccurate outputs. To address this, experts have applied reinforcement learning to improve the quality. PPO is used to fine-tune the models based on curated prompts and enhance the performance to provide more user-friendly responses. It was use in step 3 when we trained the RL model.

In this context, the policy refers to the pre-trained Language Model (LLM) that is being fine-tuned. We construct both the policy function and the value function.

- The policy function is responsible for generating sentences in a specific prompt. It can be a large language model
- The value function is The scalar value obtained from the reward function. It measures the expected value of an input (prompt) or a state-action pair and is used to estimate the advantage of action during policy updates.

To apply the PPO algorithm for language model training, the training process typically involves the following steps:

- Data Sampling: Use the current model to generate responses and collect training data.
- Model Update: Apply the PPO algorithm to update the model parameters based on the collected training data.
- Model Evaluation: Evaluate the model's performance by calculating metrics such as accuracy, perplexity, or similar evaluation measures.

## Comparing PPO with other algorithms

- _RAFT Alignment_: It is a method in transfer learning that leverages knowledge learned from a source task to a related target task. It allows reusing learned knowledge from the source model to quickly achieve high performance on the target task without retraining from scratch.
- _TRPO_: It utilizes an optimization mechanism that ensures gradual policy changes and restricts policy updates within a trust region. It guarantees that policy updates do not cause significant changes and instability. TRPO is a powerful algorithm but has complex computations and longer training times. In contrast, PPO is a simpler, more efficient, and stable algorithm.
- _PPO2_: It is simply an updated version of the algorithm released by OpenAI. PPO2 is an implementation optimized for GPU-accelerated vectorized environments and provides better support for parallel training. While it has some differences (e.g., automatically normalized advantages and clipped value functions), it uses the same mathematical framework as described in this article. If you plan to use the OpenAI implementation directly, keep in mind that PPO is outdated, and you should use PPO2 instead.

To summarize, PPO has quickly gained popularity in continuous control problems. It seems to strike a suitable balance between speed, caution, and usability. While lacking theoretical guarantees and mathematical intricacies like natural gradients and TRPO, PPO tends to converge faster and perform better compared to its competing counterparts.

## References

- https://towardsdatascience.com/proximal-policy-optimization-ppo-explained-abed1952457b
- https://medium.com/@mlblogging.k/reinforcement-learning-for-tuning-language-models-how-chatgpt-is-trained-9ecf23518302
- https://openai.com/research/learning-to-summarize-with-human-feedback


Proximal policy optimization (PPO) is an algorithm that aims to improve the stability of training by avoiding overly large policy updates. It is a popular and effective method used for training [ reinforcement learning]() models in complex environments. To achieve this, PPO uses a ratio that indicates the difference between the current policy and the old policy and clips this ratio within a specific range, ensuring that the policy updates are not too large and the training process is more stable...

Proximal policy optimization


In [Reinforcement Learning](reinforcement-learning.md), we are familiar with the function that computes rewards for an agent's actions in an environment. And these rewards are becoming increasingly complex for different machine learning programs, especially for programs where rewards are hard to define. For large language models, this reward is represented as a scoring system evaluating the model's answer quality, which helps the model generate better responses. The combination of reward models and reinforcement learning has enabled the widespread use of large language models by aligning models with acceptable human values. Reward modeling and RLHF are the most common terms in AI since the release of GPT-3.5.

## Common reward models

Reward models are often defined based on factors such as the agent's goals, environmental conditions, and specific problem rules and constraints. They can be represented as reward tables or functions, depending on the specific problem.

- **Sparse reward**: Provides rewards infrequently and sparsely during the interaction process. Rewards are given only when the agent achieves a goal or meets certain specific conditions.
- **Dense reward**: Provides relatively frequent and detailed rewards during the interaction process. Each action of the agent is evaluated and rewarded with a small reward value. This dense reward model can help the agent learn faster and generate better behavior.
- **Shaped reward**: Uses shaped reward functions to provide rewards to the agent. Instead of providing binary rewards (0 or 1), it evaluates the level of achievement for each action with a continuous value.
- **Intrinsic reward**: Rewards generated by the environment itself or by an intrinsic mechanism. It is not dependent on external goals that the agent needs to achieve but focuses on exploration and learning.
- **Adversarial reward**: Evaluates rewards based on an opponent or competitive behavior. It is often used in competitive problems or two-player games.
- **Self-supervised rewards**: Another approach is to use self-supervised rewards, where the model generates its own reward signals based on auxiliary tasks or internally defined objectives. This allows the LLM to learn how to reward itself for behavior that aligns with its internal goals.
- **Contrastive rewards**: The reward model can employ contrastive rewards to compare and evaluate the difference between two or more actions or states. This helps the model learn how to optimize its behavior to achieve better results compared to alternative choices.

## Applying Reward model to LLM

The reward model can be used in a part of the LLM training process to determine the "correct" or "reasonable" level of the model's predictions. The reward model can generate reward signals to evaluate the quality of the answers generated by the LLM. Ultimately, the reward model helps improve the output of the model. The diagram below illustrates the application of the reward model in training to create a language model.

![](assets/reward-model_reward-mode-flow.webp)

The training data for the reward model consists of ranked results of answers to the same question:

```
    {
        "text": "Why is the unemployment rate in Russia at its lowest in history?",
        "role": "prompter"
    },
    {
        "text": "The unemployment rate in Russia is at its lowest in history due to the expansion of business, which increases the demand for manpower, especially in the industrial sector.",
        "role": "assistant"
    },
    {
        "text": "The main reason is the expansion of business, which increases the demand for manpower, especially in the industrial sector.",
        "role": "assistant"
    },
    {
        "text": "The main reason is the expansion of business, which increases the demand for manpower, especially in the industrial sector. Additionally, due to sanctions from the West, Russian businesses have to seek domestic supply sources instead of importing from abroad. The Russian government aims to be self-sufficient in providing goods and services.",
        "role": "assistant"
    },
    {
        "text": "Due to limited labor resources, businesses are trying to attract employees by increasing salaries and improving working conditions.",
        "role": "assistant"
    },

```

### Characteristics of the reward model

- The reward model is also a large language model based on the transformer algorithm, so it can have a large number of parameters (billions of parameters).
- It utilizes multiple datasets for training to achieve better results:
  - It uses human-generated rankings and labels for evaluating the results of the LLM.
  - Humans create results from given prompts.
  - It leverages human chat history.
- The output of the reward model is a reward that is transformed into a scalar value from the input text.
- The foundation model of the reward model influences the quality of the reward.

### Some issues when applying the reward model

- RL models try to generate results to achieve high rewards without fully understanding the question or task.
- The model will optimize according to what the reward model is trained on, leading to suboptimal performance in other knowledge domains.
- Complex and costly feedback collection: Sometimes, collecting feedback from humans or experts can require significant effort and expenses.

## Conclusion

However, determining a suitable reward model is not always easy. Sometimes, defining a reasonable and appropriate reward model that aligns with the goals and constraints of the problem is a challenge for designers of reinforcement learning systems. Applying the reward model to the LLM training process becomes a crucial step in improving the quality and acceptance of answers from the LLM.

## References

- <https://huggingface.co/docs/trl/main/en/reward_trainer>
- <https://explodinggradients.com/reward-modeling-for-large-language-models-with-code>
- <https://huggingface.co/docs/trl/main/en/detoxifying_a_lm>
- <https://openai.com/blog/chatgpt>


A Reward model is a critical component in Reinforcement Learning for Large Language Models (LLMs), designed to evaluate and score the quality of generated responses. It plays a key role in aligning LLMs with human values and improving their output through iterative refinement.

Reward model


Q-learning is a model-free reinforcement learning algorithm used to learn an optimal policy in a Markov Decision Process (MDP). It is an off-policy method, meaning that it learns by observing and updating a value function based on the maximum expected future rewards.

Q-learning has applications in various domains, including autonomous robotics, traffic signal control, resource management, and more. The core idea behind Q-learning is to iteratively update the Q-values based on the agent's experiences. The agent explores the environment, takes actions, and receives rewards. With each interaction, the Q-values are updated using a formula that incorporates the reward received, the maximum Q-value of the next state, and a learning rate.

![](assets/q-learning-demo.webp)

## Main components

![](assets/q-learning_reinforcement-learning-architecture.webp)

- **Agent**: The entity that interacts with the environment and learns from it.
- **Environment**: The external environment in which the agent operates and receives feedback.
- **State**: The current situation or configuration of the environment.
- **Action**: The decision or choice made by the agent in a given state.
- **Reward**: The feedback or reinforcement signal received by the agent after taking an action in a particular state.
- **Episode**: A sequence of interactions between the agent and the environment, starting from the initial state until a terminal state or goal is reached.
- **Policy**: The strategy or set of rules that the agent uses to determine its actions in different states.

## How it works

The working of Q-learning involves the following steps:

- Initialize a Q-table: Create a table with rows representing states and columns representing actions. Initialize the Q-values arbitrarily.
- Choose an action: Based on the current state and the Q-values, select an action using an exploration-exploitation strategy.
- Perform the action and observe the reward and next state: Execute the chosen action in the environment and receive the reward and the resulting next state.
- Update the Q-value: Update the Q-value of the current state-action pair using the Bellman equation, which combines the immediate reward and the maximum expected future rewards from the next state.
- Repeat steps 2-4 until convergence or a predefined number of iterations.

However, it has limitations, such as the need for large storage space for state-action pairs, difficulties in handling complex and interdependent environments, and challenges in dealing with continuous states (approximation techniques may be required). Thus Deep Q-Learning extends Q-learning was born by using a deep neural network as a function approximator to handle high-dimensional state spaces. It allows for learning in complex environments and can achieve better performance.The algorithm employs an epsilon-greedy action selection strategy to balance exploration and exploitation of the environment. The learning process is based on the Bellman equation, which updates the Q-value according to an optimal learning rule.

## Potential drawbacks

- Storage limitations in complex environments: The storage requirements of Q-learning can become overwhelming when dealing with large state and action spaces, making it impractical for such scenarios.
- Challenges in complex and interdependent environments: Q-learning may face difficulties in finding optimal strategies when actions have strong dependencies and long-term consequences, as it primarily focuses on immediate rewards and may not effectively capture long-term dependencies.
- Incompatibility with continuous states: Q-learning is not directly applicable to problems with continuous state spaces. While approximation techniques like discretization or function approximation can be used, they often come at the cost of reduced performance and accuracy.

It's important to note that while Q-learning has these limitations, there are techniques and variations, such as Deep Q-learning, that aim to address some of these challenges and improve its applicability in complex and continuous environments.

## References

- https://www.techtarget.com/searchenterpriseai/definition/Q-learning
- https://huggingface.co/learn/deep-rl-course/unit2/introduction


An introduction to Q-learning, a model-free reinforcement learning algorithm used to learn optimal policies in Markov Decision Processes.

Q learning


## Introduction

Reinforcement Learning (RL) is a machine learning method in which an automated system, known as an agent, interacts with a dynamic environment to learn and improve its action strategy. The goal of RL is to enable the agent to learn how to select actions in a variety of situations to maximize a reward function. Actions are iteratively repeated until the agent consistently chooses better actions for recurring situations.

## How Reinforcement learning work?

In essence, the operation process of RL is as follows:

1. The agent observes the current state of the environment through representations or features.
2. Based on the current state, the agent selects an action from the available action set.
3. The action is executed, and the agent interacts with the environment.
4. The agent receives feedback from the environment in the form of a reward, indicating the quality of the action taken.
5. The agent uses the received reward to update its action strategy.
6. The above process is repeated until the agent achieves its goal or reaches optimal performance.

## Reinforcement learning algorithms

RL algorithms typically employ a techique called "exploration-exploitation" to learn and improve the agent's strategy. During the exploration phase, the agent tries random actions to explore the environment and learn new information. In the exploitation phase, the agent selects actions based on the learned experience to maximize the obtained rewards.

RL algorithms can utilize [Q Learning](q-learning.md), where the agent learns to evaluate actions based on a Q-Table that stores the estimated values of state-action pairs. The policy gradient algorithm focuses on learning the optimal policy by maximizing the expected reward value. Deep Q-Network (DQN) uses deep learning networks to estimate Q-values and enhances learning through reinforcement learning techniques and replay memory.

## How to train models incorporated with LLMs?

Example of building a reinforcement learning algorithm for a stock trading application. We will use LLM (chatgpt) to evaluate the data and actions

- Define the problem: Define the goals and scope of the system, this includes identifying the type of assets to trade, the trading horizon, and specific trading rules for generating actions such as placing buy/sell orders or cancelling orders.
- Data Collection: Gather historical data on prices, trading volume, and relevant technical indicators related to the market. This data will be used to build the RL model and train the AI.
- Define the states: Determine the state representation of the market and the traded assets. The State could include prices, trading volume, trading indicators and any other relevant information.
- Define the actions: Define the actions that the AI can take: buy, sell, hold
- Define the rewards: Determine the reward functions to evaluate the performance of the AI. Rewards could be based on profits, return rates, or other suitable metrics aligned with your investment objectives.
- Build RL model: Constructs an RL model to estimate the action values and optimize the trading strategy.
- Train and improve: Use historical data and the RL training algorithm to improve the model and trading strategy. This process may require multiple iterations to achieve optimal performance. Use LLM to evaluate the input from environment and output of actions.
- Test and evaluate: Test the trained model and trading strategy on real-world data or a back test with dataset to evaluate performance and make adjustment if necessary. Continuously update the model and strategy over time to ensue ongoing performance and optimize trading outcomes.

## To be continued

While RL can be applied to various domains, it requires significant time and computational resources to train the model. However, with its ability to learn and explore from experience, RL can achieve optimal performance in complex and uncertain tasks and purpose.

## References

- https://www.andrew.cmu.edu/course/10-703/textbook/BartoSutton.pdf
- https://github.com/jihoonerd/Deep-Reinforcement-Learning-with-Double-Q-learning/tree/master/paper
- https://medium.com/ibm-data-ai/recommendation-systems-using-reinforcement-learning-de6379eecfde
- https://towardsdatascience.com/how-to-create-a-fully-automated-ai-based-trading-system-with-python-708503c1a907

## Glossary

- Agent: The interacting entity operates with the environment, and its actions are controlled by an algorithm.
- MDP: Markov decision process
- LLM: Large language model


An introduction to Reinforcement Learning (RL), a machine learning method where an agent learns to make decisions by interacting with an environment. This article covers the basics of RL, including how it works, common algorithms, and its application in training models with Large Language Models (LLMs).

Introduction to reinforcement learning and its application with LLMs


During our research on applying LLM to real-world applications, we have observed the widespread usage and increasing popularity of Vector databases in various fields. Therefore, we have delved into understanding and summarizing what we have learned in this article.

## History of vector database

Vector databases have emerged as a crucial component in natural language processing and machine learning. They are built upon the idea of representing data as vectors in high-dimensional spaces. Vector databases efficiently store and retrieve vector representations, allowing for fast similarity-based searches. They have evolved from word embeddings to support various linguistic units and complex data structures. By leveraging vector databases, models like GPT can access and utilize pre-computed vector representations, enhancing their semantic understanding and information retrieval capabilities. The development of vector database technologies is expected to continue advancing, providing more sophisticated solutions for managing and utilizing vector representations in diverse applications.

## What is vector database

A vector database is a specialized database designed to store, manage, and query vector data. Unlike traditional databases that focus on structured data, vector databases are optimized for the storage and manipulation of high-dimensional vector representations. They enable efficient handling of vector data, allowing for complex operations such as vector similarity search, clustering, and recommendation.

## Use case of vector database

- Long term memory for LLM
- Semantic search: search base on the meaning of the context
- Similarity search for text, image, audio, video data
- Personalization and Recommendation engine: storing and querying user preferences or behavior vectors.
- Biometrics and Identity Verification: fingerprint matching, voice recognition, and facial recognition.
- Fraud Detection and Anomaly Detection: historical data or user behavior patterns to identify fraudulent activities, detect anomalies in data streams, and flag suspicious patterns

## Core concept of vector database

- Data is transformed into vectors using a specific algorithm, and similar data points on the same coordinate system have close distances.
- Data is stored in a data structure optimized for vector queries.
- Indexing in vector databases differs from traditional databases. Vector databases use algorithms like KD-tree and LSH for clustering and sorting.
- Searching in vector databases:
  - Nearest neighbor search: Find the nearest vector to a given input vector.
  - Similarity computation: Calculate the similarity between vectors using metrics like Euclidean distance and cosine similarity.
- Implementation considerations:
  - Choosing the appropriate number of dimensions for vectors is important for performance and storage resource utilization, ensuring coverage of the entire dataset.
  - Selecting the suitable search algorithm (Cosine similarity, DotProduct, Euclidean distance).

## Using vector database with LLM

### Choosing the right vector encoding

LLMs typically use models like Word2Vec, BERT, and transformer-based variants.

### Configuring proper vector search parameter

To achieve optimal efficiency, configure the search parameters appropriately. Pay attention to parameters such as:

- Match threshold: 0.78
- Match count: 10
- Minimum content length: 50

### Selecting the suitable metric for content

- Cosine Similarity:
  - Cosine Similarity calculates the cosine of the angle between two vectors. It measures the directional similarity of vectors.
  - The Cosine Similarity value ranges from [-1, 1], where 1 represents identical vectors and -1 represents completely opposite vectors.
  - This algorithm is commonly used in tasks like text classification, recommendation systems, and natural language processing.
- Dot Product:
  - Dot Product calculates the dot product of two vectors, which is the sum of the products of their corresponding components.
  - The result is a scalar value that indicates the level of linear correlation between two vectors.
  - The Dot Product algorithm is often used in applications such as machine learning, data clustering, and image recognition.
- Euclidean Distance:
  - Euclidean Distance calculates the Euclidean distance between two vectors. It measures the length-based distance between two points in space.
  - The Euclidean Distance value is a positive number that represents the direct distance between two vectors.
  - This algorithm is commonly used in tasks such as clustering, classification, and image processing.
- Indexing Choices on Some Databases:
  - Pinecone: Choose based on Pods and quantity.

## Compare popular vector database

|                                                  | Pinecone                  | Qdrant                                       | Supabase     | Weaviate                               | Milvus                                                                       | Chroma |
| ------------------------------------------------ | ------------------------- | -------------------------------------------- | ------------ | -------------------------------------- | ---------------------------------------------------------------------------- | ------ |
| Build for vector database                        | y                         | y                                            | n            | y                                      | y                                                                            | y      |
| Open source                                      | n                         | y                                            |              |                                        | y                                                                            | y      |
| Roll-based Access Control (RBAC)                 | y                         | No. Authentication only                      | y            | Coming soon                            | y                                                                            |        |
| Disk Index support                               | y                         | y                                            | y            | y                                      | y                                                                            |        |
| Hybrid Search (ie Scalar filtering)              | Yes with Scalar filtering | Yes (combine vector and traditional indices) | y            | Yes (combine Sparse and Dense Vectors) | Yes with Scalar filtering                                                    |        |
| Partitions/namespaces/logical groups             | y                         | n                                            | y            | n                                      | y                                                                            |        |
| Index type supported                             | y                         | 1 (HNSW)                                     | B-Tree, Hash | 1 (HNSW)                               | 9 (FLAT, IVS_FLAT, IVF_SQ8, IVF_PQ, HNSW, ANNOY, BIN_FLAT, and BIN_IVF_FLAT) |        |
| Database rollback                                | y                         | y                                            | y            | y                                      | y                                                                            |        |
| Tunable consistency                              | y                         | y                                            | y            | y                                      | y                                                                            |        |
| Support for both stream and batch of vector data | y                         | n                                            | y            | y                                      | y                                                                            |        |
| Binary Vector support                            | y                         | n                                            | y            | y                                      | y                                                                            |        |
| Multi-language SDK                               | Python, Node.js           | Python, Go, Rust                             | y            | Python, Java, Go                       | Python, Java, Go, C++, Node.js                                               |        |

These vector databases offer various features and optimizations to handle large-scale vector data efficiently. The choice of the most suitable vector database depends on factors such as the specific requirements of your language model, the size of the dataset, the expected query throughput, and the available hardware resources. It is recommended to evaluate and benchmark different vector databases to determine which one best fits your specific use case.

## References

- [https://qdrant.tech/benchmarks/?gad=1&gclid=Cj0KCQjwsIejBhDOARIsANYqkD0ZtNrEujSDsjGPsOmSGRtJaIYvQct3kvojBEQPJxrcdL7lC9IaLVQaAnMjEALw_wcB](https://qdrant.tech/benchmarks/?gad=1&gclid=Cj0KCQjwsIejBhDOARIsANYqkD0ZtNrEujSDsjGPsOmSGRtJaIYvQct3kvojBEQPJxrcdL7lC9IaLVQaAnMjEALw_wcB)
- [https://slashdot.org/software/comparison/Embeddinghub-vs-Milvus-Database-vs-chroma/](https://slashdot.org/software/comparison/Embeddinghub-vs-Milvus-Database-vs-chroma/)


An overview of vector databases and their application in LLM systems. This article covers the history and core concepts of vector databases, their use cases, implementation considerations with LLMs, and a comparison of popular vector database options.

Select vector database for LLM


Currently, AI chatbot services like ChatGPT are being widely used, but these services are restricted in many countries and also prohibited by many schools due to the high quality of results they produce compared to the level of students’ knowledge. Additionally, these services also require high costs to generate results. Therefore, I think that if we can run a personal chatbot for use with acceptable results and without hardware costs, you can run it on your personal computer with a minimum requirement of 8GB of RAM. In this post, I will guide you on how to run a personal chatbot with an open model like Alpaca 7b or gpt4all model.

## What is pre-trained models?

The LLM pre-trained model is designed to generate more coherent and contextually relevant text than traditional language models. By using latent variables, the model can better capture the complex relationships between words and phrases in natural language. Additionally, the LLM model is highly customizable, allowing users to specify the structure and complexity of the latent variables to suit their specific needs.

Overall, the LLM pre-trained model is a powerful tool for natural language processing tasks and has been used successfully in a variety of applications, including machine translation, summarization, and dialogue generation, chatbot, virtual assistant.

## Preparing for build AI chatbot

- Use HuggingFace to download the model: Download the model from HuggingFace.
- Download the chatbot interface source code: requires skill of git, running Node.js, and installing with yarn.
- Update the model and run the chatbot: Update config.

## Install chatbot UI

- Clone chatbot web ui from this repository: [here](https://github.com/ngxson/alpaca.cpp-webui)
- Download chat binding library and open model:

  - Download binding library from:
  - Download open Alapace model 7B from [here](https://huggingface.co/Sosaka/Alpaca-native-4bit-ggml/blob/main/ggml-alpaca-7b-q4.bin)
  - Move binding library and model to folder bin
  - Config model in config.json

    - Example config model alpaca 7B

      ![](assets/build-your-chatbot-with-open-source-large-language-models_build-chatbot-1.webp)

- Install node library and run

  - Run `yarn install` inside repository root folder
  - Start web and waiting load model, Run command: `yarn dev` to start the web. You will see the log after run command: ![](assets/build-your-chatbot-with-open-source-large-language-models_build-chatbot-2.webp)

- Otherwise, you can use other bigger model to improve the output
  - Using Alpaca 13B model, it require more memory. Download Alpaca 13B from [here](https://huggingface.co/eachadea/ggml-gpt4-x-alpaca-13b-native-4bit/blob/main/gpt4-x-alpaca-13b-native-ggml-q4_0.bin)
  - Using gpt4All model, require another binding library from [here](https://github.com/nomic-ai/gpt4all/tree/main/chat) depending on your OS and download model from [here](https://huggingface.co/4bit/gpt4all-lora-quantized/blob/main/gpt4all-lora-quantized.bin)
  - Using Alpaca 30B model, I had try using model gpt4-x-alpaca-30b-ggml-q4_1 but system cannot load it.
  - Using Alpaca 7B tunning with GPT4
- Test chatbot
  - You can ask chatbot like this ![](assets/build-your-chatbot-with-open-source-large-language-models_build-chatbot-3.webp)

## Fine-tune your model

To fine tune your model you need create your dataset depend on your data, you can clone our example at [here](https://github.com/thanhpn/df-dataset)

We are using Google colab to train pre-trained model, you can follow the code example at [here](https://colab.research.google.com/drive/1TbV-Enz4O__GFXtqUWEFK0snYedOwPTh?usp=sharing)

## Comparing the chatbot with ChatGPT3

For models with a large number of parameters, such as 30 billion or more, the results generated can be used as a suggestion for further research, but the quality of the answers will not be comparable to ChatGPT3.

## References

- <https://huggingface.co/docs/timm/main/en/quickstart#finetune-a-pretrained-model>
- <https://github.com/EwingYangs/awesome-open-gpt/tree/main>
- <https://github.com/nomic-ai/gpt4all>


A guide on how to build a personal AI chatbot using open-source Large Language Models (LLMs) like Alpaca and GPT4All on your personal computer.

Build your chatbot with open source large language models


## Introduction

![](assets/plonky2_plonky-2-website.webp) Plonky2 is a non-Interactive Proof of Proof of Knowledge (NIPoPoK) chain developed to reduce the size of the blockchain and speed up transaction confirmations. It is built on the foundation of ZK-SNARKs (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge), an advanced cryptographic technology that enables affirmative proofs without revealing inside information. Plonky2 allows transactions to be confirmed on the fly using certificates similar to Merkle trees, where only a small portion of data is needed to confirm the entire Merkle tree. Plonky2 certificates are very small, only about 1/20th of similar attestations used in traditional blockchain systems, thus helping to reduce blockchain size and speed up transaction processing. Plonky2 is being used in several blockchain projects such as Ethereum and Polkadot to improve the performance and scalability of the system.

## The target of Plonky2

Blockchain is a decentralized information storage and conversion technology that allows parties to exchange information and transact directly with each other without the involvement of an intermediary. Transactions are confirmed and written to a new block in the blockchain, forming a reliable and unmodifiable history of transactions. An important issue of blockchain is its size. Since each new block added to the blockchain must be stored and backed up across the entire network, the size of the blockchain increases over time. This leads to problems with transaction processing speed, scalability, and storage costs.

Some blockchains like Bitcoin use Proof of Work (PoW) to verify new transactions and generate new blocks. However, the use of PoW requires huge computation and high energy usage, negatively affects the environment and is costly. So many new technologies have been developed to solve the blockchain size problem, speed up transaction processing and reduce storage costs. Plonky2 is one of those new technologies, with the ability to reduce blockchain size significantly using non-interactive attestation (NIPoPoK) and Merkle tree structure.

Plonky2 is a new technology in the blockchain field, developed to reduce blockchain size and speed up transaction confirmation by using non-interactive attestation (NIPoPoK) and Merkle tree structure. NIPoPoK is a method of building attestations for blocks in the blockchain without downloading the entire blockchain, requiring only a small number of blocks (usually only about 1% of the total block) called "superblocks". With NIPoPoK, confirmation of new transactions becomes faster and requires less resources than confirmations on the entire blockchain.

The Merkle tree is a layered data structure that allows for fast and efficient data integrity checking. Using the Merkle tree structure in Plonky2, the blocks of the blockchain can be grouped into smaller "superblocks", which reduces the blockchain size significantly. The use of Plonky2 in the blockchain will help speed up transaction confirmations and reduce blockchain size, while reducing storage costs and increasing the scalability of the system. Plonky2 has been used in many blockchain projects, such as Ethereum and Bitcoin Cash.

## How Plonky2 work

Non-Interactive attestation (NIPoPoK) is a method of attesting in the blockchain without interacting with other entities in the system. Instead of downloading the entire blockchain to confirm a block, NIPoPoK requires only a small number of blocks (usually only about 1% of the total block) called "superblocks" to verify the validity of a new block. The main difference between NIPoPoK and interactive attestation (PoK) is that PoK requires interaction between entities in the system for authentication. This means that entities must exchange information with each other to perform authentication. Meanwhile, NIPoPoK does not require interaction between entities, which minimizes communication and synchronization in the system. The other difference between NIPoPoK and PoK is that PoK typically uses more complex protocols for authentication, while NIPoPoK uses simpler maths to compute authentication. However, this does not mean that NIPoPoK is less secure, because NIPoPoK uses the latest techniques to ensure the safety and security of data. With the development of technology, NIPoPoK is being widely used in blockchain to minimize the interaction and synchronization in the system, while helping to speed up transaction confirmation and reduce blockchain size.

Merkle tree is a binary tree data structure used to store data and perform data integrity validation efficiently. Merkle trees are widely used in blockchain systems to minimize data size and speed up transaction integrity validation. Merkle tree is created by breaking data into smaller elements, called leaf nodes, then creating pairs of these leaves and hashing them together to form new nodes, until there are only leaves left. a single node at the top of the tree, called the root node. When there is a change in the data, simply recalculate the hash of the affected nodes and the root node will change, helping to verify the integrity of the data quickly and efficiently.

Plonky2 uses a Merkle tree to verify transaction integrity. Instead of validating the entire blockchain like other methods, Plonky2 simply uses a small number of blocks (superblocks) created by the Merkle tree to verify the validity of a new transaction. Since then, Plonky2 reduces the size of data to be processed and speeds up transaction validation significantly. Merkle tree is used to generate superblocks, where each superblock is created by taking root nodes of Merkle trees for a certain period of time. Superblocks are stored in a linked list, and Plonky2 uses this list to verify the integrity of the new transaction. If a transaction is invalid, Plonky2 will re-query the superblock to find the invalid transaction and thereby confirm the integrity of the system.

## Application of Plonky2

### Blockchain projects using Plonky2 and how Plonky2 improves system performance and scalability:

- Mina Protocol: This is currently the smallest blockchain with a size of only about 22KB, using Plonky2 to reduce the size of the blockchain and increase transaction processing speed.
- Coda Protocol: Similar to Mina Protocol, Coda Protocol uses Plonky2 to reduce the size of the blockchain and increase transaction processing speed.
- Manta Network: Manta Network is a decentralized finance (DeFi) platform on the Polkadot network, using Plonky2 to reduce the size of the blockchain and increase transaction processing speed.
- Ergo: Ergo is a new decentralized blockchain, using Plonky2 to reduce the size of the blockchain and increase transaction processing speed.

### Example for using Plonky2

An example of the use of Plonky2 is in the blockchain system of rewards points for loyalty programs. This system uses Plonky2 to reduce the size of the blockchain and speed up transaction processing.

In this system, each time a customer makes a purchase or uses the company's service, they will be allocated a number of reward points corresponding to the amount spent. These reward points are recorded on the blockchain and can be used in exchange for other products or services of the company. However, because the number of customers and the number of transactions in the system can be very large, recording every transaction on the blockchain can lead to the blockchain being too large and the transaction processing slow.

To solve this problem, the system uses Plonky2 to reduce the size of the blockchain. Instead of recording every transaction on the blockchain, the system only stores the transaction summary (transaction summary) as a Merkle tree. Plonky2 is used to confirm these transaction summaries and prove that all the transactions that have been performed are valid. As a result, this reward points blockchain system can process thousands of transactions per second, and the blockchain size increases only slightly if the number of customers and transactions increases.

## Challenge of Plonky2

### Safety and security issues when using Plonky2

![](assets/plonky2_tradeoffs.webp)

During authentication, Plonky2 asks the nodes to specify a specific number of Merkle tree elements. However, if a node sends incorrect elements or changes the Merkle tree, it can cause validation errors and affect the integrity of the blockchain. Therefore, ensuring the correctness of the Merkle tree is very important.

In addition, Plonky2 also depends on the security of the hash system and the elliptic curve. If one of these factors is broken, then the authentication will not be secure and lead to security problems. Another problem for Plonky2 is a preimage attack, where an attacker uses previously known information to find secret hashes. If attacked, Plonky2 will no longer guarantee the integrity of the data. Therefore, when using Plonky2, developers need to pay attention to security and safety issues to ensure the integrity and security of the blockchain system.

### Challenges in implementing and using Plonky2 on different blockchain systems

- Plonky2 Complexity: Plonky2 is a new technology and its complexity can make it difficult to deploy on different blockchain systems.
- Compatibility: Some blockchain systems have separate processes and features, so integrating Plonky2 into these systems can be difficult.
- Reliability and security: Deploying Plonky2 requires the reliability and security of the software, and a security incident can lead to the loss of assets and currency.
- Processing speed: Plonky2 can help speed up transaction processing, but implementation on different blockchain systems may require time and effort to optimize performance.
- Scalability: Plonky2 is a highly scalable technology, but deployment on different blockchain systems may require different configurations and management to achieve maximum scalability. .

## Compare Plonky 2 with others

- Lightning Network: Lightning Network is a technology developed on the Bitcoin platform to reduce the cost and time of transaction processing. Lightning Network uses an offline payment channel to minimize communication between network nodes and speed up transaction processing. However, Lightning Network does not solve the blockchain size problem like Plonky2.
- Sharding: Sharding is a method of distributing data across many different nodes to reduce the load on each node and increase transaction processing speed. However, Sharding also faces many challenges in terms of security and compatibility with other systems.
- Sidechain: Sidechain is a technology that allows the creation of sub-blockchains to process different transactions. These sub-blockchains are linked to the main blockchain and can offload the main blockchain. However, linking between the secondary blockchains and the main blockchain can cause some security issues.

### Comparison between Plonky2 and other technologies in improving the performance and scalability of the blockchain system:

- Plonky2 vs. SegWit: SegWit (Segregated Witness) is a solution used on the Bitcoin network to reduce transaction size and increase processing speed. However, SegWit cannot solve the problems related to network scalability. Meanwhile, Plonky2 uses a number of different techniques such as Merkle tree and non-interactive attestation to reduce blockchain size and speed up transaction processing, while improving the scalability of the system.
- Plonky2 vs. Lightning Network: Lightning Network is a technology used to reduce costs and speed up transaction processing on the Bitcoin network. However, Lightning Network cannot solve the problem of network scalability. Meanwhile, Plonky2 reduces the blockchain size and increases transaction processing speed without compromising the safety and security of the system, while improving the scalability of the network.
- Plonky2 vs. Sharding: Sharding is a solution used to improve the scalability of the blockchain system by dividing the blockchain into parts and processing them independently. However, Sharding has limitations on the safety and security of the system. Meanwhile, Plonky2 helps to reduce blockchain size and speed up transaction processing without affecting the safety and security of the system.
- Plonky2 vs. Plasma: Plasma is a solution used to improve Ethereum's scalability by layering and processing transactions on sidechains.

## Reference

- https://polygon.technology/blog/plonky2-a-deep-dive
- https://github.com/mir-protocol/plonky2
- https://hackernoon.com/zero-knowledge-proof-algorithm-plonk-circuit-sin7y-tech-review-16
- https://vitalik.ca/general/2019/09/22/plonk.html
- https://zkresear.ch/t/composition-of-proof-systems/43


Plonky2 is a non-Interactive Proof of Proof of Knowledge (NIPoPoK) chain that reduces blockchain size and speeds up transaction confirmations. This article explores Plonky2's technology, its applications in various blockchain projects, and compares it with other scaling solutions.

Plonky2


## Polygon zkEVM architecture

The main purpose of this architecture is Efficiency, the first strategy is incentivize the most efficient aggregators to participate in the proof generation process. The second is move all computation off-chain but keep only the necessary data zk-proof on-chain. Make the bridge decentralize. Utilization of special cryptographic primitive within the zkProver in order to speed up computation and minimize proof size.

![](assets/polygon-zkevm-architecture_polygon-zkevm.webp)

### Main components:

- **Proof of efficiency** is a consensus mechanism based on an automatically conducted decentralized auction, with participants bidding on a certain amount of tokens to be selected to create the next batch added support for permissionless participation of multiple coordinators to create batches in L2
- **zkNode** is software to be run by any zkEVM node, it not required to install Synchronization and adjust the roles of the participants. They can join as a node to know the state of the network, or can participate in production processing in any role: Sequencer or Aggregator.
  - Synchronizer
  - Sequencer & Aggregators
  - RPC

![](assets/polygon-zkevm-architecture_fig3-zknode-arch-aa4d18996fba1849291ea18e3f11d955.webp)

- **zkProver** is techinal to create validity proof using zero-knowledge. it consists of a main state machine executor ( a collection of secondary state machines), a STARK proof builder, and a SNARK-proof builder. All valid batch must satisfy specific polynomial constraint.

![](assets/polygon-zkevm-architecture_polygon-zkprover.webp)

- **LX-to-Ly bridge** is a smart contract can help users transfer assets between two layers.

### How does it work?

#### What is Proof of efficiency?

PoE solve the problem relate to decentralized and permissionless validators in Layer 2. Using zk-STARK for proving purpose, this proof are very fast but they are very big size. So, using zk-SNARK to attest to the correctness of the zk-STARK proofs. This help in reducing the gas cost from 5M to 350k.

**Sequencer** create a batch of Layer 2 transaction from users and so select and pre-process a new L2 batch in network by sending a L1 tx with the data of all selected Layer 2 TXs. The transaction in L2 will be in format on L1 transaction with information in the **CALLDATA**, it will be used as the data available for the L2 network and L2 node will be able to synchronize the state. The new state is settled (validity proof of new state is generated and mined in L1) these data availability on L1 transaction define the L2 TXs that will be executed in specific order.

The batch is process when the sequencer to do base on the incentives they have:

![](assets/polygon-zkevm-architecture_1b54ce784c821f34b8d5d7218850095a84c9e054.webp)

**Aggregators** receives all transaction information form Sequencer and send it to prover to get proof and send proof to smart contract to check. The first aggregator submit the proof will earn the right to create the validity proof of new state of the Layer 2

![](assets/polygon-zkevm-architecture_6066873078dcd11f9ef93601eba9237c52cbf11a.webp)

This mechanism will avoid control of a single party and many of the potential attacks, since any Sequencer can propose a batch, but there is a cost on it.

#### How to incentivization for Sequencer and Aggregators?

The two permissionless participants of the zkEVM network are: Sequencers and Aggregators. Proper incentive structures have been devised to keep the zkEVM network fast and secure. Below is a summary of the fee structure for Sequencers and Aggregators:

- **Sequencer**
  - Collect transactions and publish them in a batch
  - Receive fees from the published transactions
  - Pay L1 transaction fees + MATIC (depends on pending batches)
  - MATIC goes to Aggregators
  - Profitable if: txs fees > L1 call + MATIC fee
- **Aggregator?**
  - Process transactions published by Sequencers
  - Build zkProof
  - Receive MATIC from Sequencer
  - Static Cost: L1 call cost + Server cost (to build a proof)
  - Profitable if: MATIC fee > L1 call + Server cost

#### zkEVM

zkEVM was design to take advantage of ZK folklore to minimize size validity proof for validation, reduce transaction finality time and save gas costs.

![](assets/polygon-zkevm-architecture_polygon-zk-prover-design-approach.webp)

#### zkProver

Have 4 main components:

- The Executor, which is the Main State Machine Executor
- The STARK Recursion Component
- The CIRCOM Library
- The zk-SNARK Prover

Prover generate verifiable proof process:

![](assets/polygon-zkevm-architecture_fig-main-prts-zkpr.webp)

You can read more [here](https://docs.hermez.io/zkEVM/zkProver/Overview/zkProver-Overview/#the-stark-recursion-component)

#### Bridge flow

**The Bridge L1 contract** have two operations, it requires two Merkle trees in order to work: globalExitTree and mainnet exit tree.

- **bridge** transfer asset from one rollup to another
- **claim** make claim from any rollup

**The Bridge L2 contract** named the global exit root manager L2 is responsible for managing the exit roots across multiple networks.

#### RPC

Provide a RPC interface compatible with ethereum so application like Metamask, etherscan can connect and interact. RPC also add transactions o the pool and interact with the state via read-only methods.

#### State

State implement a Merkle Tree and connect to DB backend. it checks integrity of block, transaction information. State also stores smart contract code in to the merkle tree and process transaction using EVM.

## Reference

- [Polygon zkEVM documentation](https://docs.hermez.io/zkEVM/Basic-Concepts/Intro-zkProver%27s-Design-Approach/)
- [Proof of efficiency](https://ethresear.ch/t/proof-of-efficiency-a-new-consensus-mechanism-for-zk-rollups/11988)
- [LX-to-LY bridge](https://wiki.polygon.technology/docs/zkEVM/lx-ly-bridge)
- [zkEvm](https://wiki.polygon.technology/docs/zkEVM/proof-of-efficiency)
- [Repo zkevm](https://github.com/0xPolygonHermez/zkevm-node)
- [Polygon zkEVM](https://mirror.xyz/msfew.eth/JJudP_Kf-IS6VhbF-qU0BUor1Ap6SFEb0TzYOHZ34Rc)


This article provides an overview of the Polygon zkEVM architecture, including its main components, how it works, and its benefits.

Polygon zkEVM architecture


## StarkNet layer 2 solution

StarkNet is a layer 2 blockchain solution using ZK rollup, it provides StarkDex technology for well-known applications such as dYdX, ImmutableX, Sorare. It allows decentralized exchanges to process transactions with fast speed and low costs. Its essence is to reduce computations, store on-chain, replace with off-chain computations and store off-chain, Store balance using merkle tree with root merkle tree stored on-chain

![](assets/starknet-architecture_starkdex.webp)

## StarkNet architecture overview

The system consists of 6 main components:

- **User account** is a smart contract and expands the ability to create a recovery mechanism that depends on social information such as friends, family, colleagues, can handle offline authentication instead of use seed phrases. There is now an Argent X wallet that uses this method.
- **Sequencer** validates off-chain transactions, manages orders, verifies and bundles transactions into blocks. The system has only 1 sequencer to ensure it works consistently. It also uses a virtual machine similar to EVM called Cairo
- **Prover** generates proof to verify transactions wrapped by sequencer to generate global state by processing transactions in new block. To generate a valid proof it requires an execution trace of the Sequencer's computations. Prover generates proof for all other applications running on StarkEx.
- **Full node** is a component that keeps a record of all transactions made during the rollup and tracks the global state of the network. They communicate p2p sharing information about the global state and validating every time a new block is created.
- **Verifier** is a smart contract running on Layer 1 Ethereum that is responsible for verifying on-chain proofs generated by Prover and transactions on Layer 1. Verification results are sent to smart contract StarkNet core for storage. and mark the start of a new set of transactions on Layer 1 from StarkNet to update the Global state on-chain.
- **StarkNet core** Is a smart contract running on layer 1 that receives changes to Layer 2 global state from StarkNet every time there is a new L2 block and its proof is successfully verified on-chain by Verifier. StarkNet Fullnode will decrypt the data in the "call data" to recreate the history of the network on the first sync

## How does it work

The process consists of four steps:

1. **Batching** is Sequencer, groups together multiple transactions into a batch for processing. The entired batch is submit on-chain as a single compressed state update with a proof.
2. **Validating & updating** The update is then compressed in the form of a hash on the entire state of the system : ℎ(ℎ(ℎ(class_hash,storage_root),0),0) Where:

- class_hash is the hash of the contract’s definition discussed here
- storage_root is the root of another Merkle-Patricia tree of height 251 that is constructed from the contract’s storage
- ℎ is the Pedersen hash function.

3. **Generating a proof** Once the batch transaction is processed, StarkEx generates a STARK proof to confirm the correctness of the transactions.
4. **On-chain verification** Once the proof is verified, the state update is committed and settled on layer 1 Ethereum

## Messaging mechanism

Contracts on L2 can interact asynchronously with contracts on L1 via the L2→L1 messaging protocol.

![](assets/starknet-architecture_starknet-current-architecture.webp)

Contracts on L1 can interact asynchronously with contracts on L2 via the L1→L2 messaging protocol. The protocol consists of the following stages:

![](assets/starknet-architecture_starknet-l1l2.webp)

## StarkNet transaction lifecycle

When the transaction is submitted to the StarkNet, it is sent to the Sequence node. **Sequencer** takes a batch of transactions and generates:

- List of changes made by transactions (storage, balance, data...)
- As a proof, if every transaction in the batch is successfully processed compared to the previous state of the network then the result will be the list of changes listed previously.

![](assets/starknet-architecture_starknet-transactions-states.webp)

## Node clients

StarkNet nodes use the [Pathfinder](https://github.com/eqlabs/pathfinder) or the [Juno](https://github.com/NethermindEth/juno) client and they are similar to the nodes running Go Ethereum

## Reference

- [StarkDEX deep dive : introduction](https://medium.com/starkware/starkdex-deep-dive-introduction-7b4ef0dedba8)
- [StarkNet’s architecture review](https://david-barreto.com/StarkNets-architecture-review/)
- [StarkNet docs](https://docs.StarkNet.io/documentation/)

### Smart contract

- [StarkNet core](https://etherscan.io/address/0xc662c410c0ecf747543f5ba90660f6abebd9c8c4)
- [StarkNet operator](https://etherscan.io/address/0x2c169dfe5fbba12957bdd0ba47d9cedbfe260ca7)


This article provides an overview of StarkNet's architecture, including its main components, how it works, and its transaction lifecycle. It also covers the messaging mechanism between Layer 1 and Layer 2, as well as the node clients used in the StarkNet network.

StarkNet architecture


Zero-knowledge proof is a way of proving the validity of a statement without disclosing the statement itself. A "validator" is the party attempting to prove a claim, while a "verifier" is responsible for validating the claim.

## Why do we need to demonstrate no knowledge?

Zero-knowledge proofs represent a breakthrough in applied cryptography, as they promise to improve the security of information for individuals. Consider how you can prove the claim (for example, “I am a citizen of country X”) to another party (for example, a service provider). You'll need to provide "proof" to back up your claim, such as a national passport or driver's license. But this approach is not safe, can be hacked, personal information can be revealed

Zero-knowledge proofs solve this problem by removing the need to disclose information to prove the validity of claims. The zero-knowledge protocol uses a statement (called a 'witness') as input to generate a succint proof of its validity. This proof provides firm assurance that a statement is true without revealing the information used to make it.

Going back to our earlier example, the only proof you need to prove your citizenship claim is zero-knowledge proof. The verifier only has to check if certain properties of the proof are true to believe that the underlying statement is also true.

## How to prove Zero Knowledge works?

To make this possible, zero-knowledge protocols rely on algorithms that take some data as input and return the 'true' or 'false' as output. A Zero-knowledge protocol must satisfy the following criteria:

1. **Completeness**: If the input is valid, the zero-knowledge protocol always returns 'true'. Hence, if the underlying statement is true, and the prover and verifier act honestly, the proof can be accepted.
2. **Soundness**: If the input is invalid, it is theoretically impossible to fool the zero-knowledge protocol to return 'true'. Hence, a lying prover cannot trick an honest verifier into believing an invalid statement is valid (except with a tiny margin of probability).
3. **Zero-knowledge**: The verifier learns nothing about a statement beyond its validity or falsity (they have “zero knowledge” of the statement). This requirement also prevents the verifier from deriving the original input (the statement’s contents) from the proof.

In basic form, a zero-knowledge proof is made up of three elements: witness, challenge, and response.

- **Witness**: with a zero-knowledge proof, the prover wants to prove knowledge of some hidden information. the secret information is the "witness" to the proof, and the prover's assumed knowledge of the witness establishes a set of questions that can only be answered by a party with knowledge of the information. Thus, the prover starts the proving process by randomly choosing a question, calculating the answer, and sending it to the verifier.
- **Challenge**: The verifier randomly picks another question from the set and ask the prover to answer it.
- **Response**: the prover accepts the question, calculates the answer and returns it to the verifier. The prover's response allows the verifier to check if the former really has access to the witness. to ensure the prover is not guessing blindly and getting the correct answers by chance, the verifier pick more question to ask. By repeating this interaction many times, the possibility of the prover faking knowledge of the witness drops significant until the verifier is satisfied.

Interactive proof and non-interactive proof:

- Interactive proof had limited usefulness since it required the two parties to be available and interact repeatedly
- Non-interactive proof required only one round of communication between participants. the provers passes the secret information to a special algorithm to compute a zero-knowledge proof. this proof is sent to the verifier, who verify that the prover knows the secret information using other algorithm.

## Types of zero-knowledge proofs

### ZK-SNARKs

ZK-SNARK is an acronym for Zero-Knowledge Succinct Non-Interactive Argument of Knowledge. The ZK-SNARK protocol has the following qualities:

- **Zero-knowledge**: A verifier can validate the integrity of a statement without knowing anything else about the statement. The only knowledge the verifier has of the statement is whether it is true or false.
- **Succinct**: The zero-knowledge proof is smaller than the witness and can be verified quickly.
- **Non-interactive**: The proof is 'non-interactive' because the prover and verifier only interact once, unlike interactive proofs that require multiple rounds of communication.
- **Witness**: The proof satisfies the 'soundness' requirement, so cheating is extremely unlikely.
- **(Of) Knowledge**: The zero-knowledge proof cannot be constructed without access to the secret information (witness). It is difficult, if not impossible, for a prover who doesn’t have the witness to compute a valid zero-knowledge proof.

For the ZK-SNARK protocol to work, the creation of a Common Reference String (CRS) is necessary: ​​The CRS provides public parameters to prove and verify valid proofs. The security of the proof system depends on the CRS setting; If the information used to create the public parameters falls into the possession of malicious actors, they can create false validators.

- Some ZK-rollups attempt to solve this problem by using multiparty computation (MPC), involving trusted individuals, to create public parameters for the ZK-SNARK circuit. Each party contributes a random number (called "hazardous waste") to the construction of the CRS, which they must destroy immediately.
- Trusted settings are used because they increase the security of the CRS setup. As long as an honest participant discards their input, the security of the ZK-SNARK system is guaranteed. However, this approach still requires the trust of the stakeholders to erase their sampled randomness and not undermine the security guarantees of the system.
- Reliability assumptions aside, ZK-SNARK is very popular because of its small proof size and continuous time verification. Since verifying proofs on L1 constitutes a greater operating cost of ZK-rollup, L2 uses ZK-SNARK to generate proofs that can be quickly and cheaply verified on the Mainnet.

### ZK-STARKs

Like ZK-SNARKs, ZK-STARKs demonstrate the validity of off-chain computation without revealing the input. However, ZK-STARK is considered an improvement on ZK-SNARK because of their scalability and transparency.

- **Scalable**: ZK-STARK is faster than ZK-SNARK in generating and verifying evidence when witness size is larger. With STARK proofs, verification and proverb times only increase slightly as the witness grows (the times of the proverb and SNARK verifier increase linearly with witness size).
- **Transparency**: ZK-STARK relies on public verifiable randomness to generate public parameters for proof and verification instead of establishing trust. Therefore, they are more transparent than ZK-SNARK.
- **Scalability**:ZK-STARKs also offer more scalability because the time required to prove and verify valid proofs increases with the complexity of the underlying computation. With ZK-SNARK, the proof and verification times expand linearly with respect to the size of the underlying computation. This means that ZK-STARK requires less time than ZK-SNARK to prove and verify as far as large data sets are concerned, making them useful for high volume applications.
- **Security**: ZK-STARK is also secure against quantum computers, while Elliptic Curve Cryptography (ECC) used in ZK-SNARK is considered by many to be vulnerable to quantum computing attacks. The downside of ZK-STARKs is that they produce a larger proof size, which is more expensive to verify on Ethereum. Also, they don't support recursion, which is key to extending off-chain computation with zero-knowledge proofs.

## Application for ZK proof

- Anonymous payments
- Identity protection
- Authentication
- Verifiable computation

## Drawbacks of using ZK proofs

- Hardware costs
- Proof verification costs
- Trust assumptions
- Quantum computing threats

## References

- [Zero-knowledge proofs](https://ethereum.org/en/zero-knowledge-proofs/)
- [ZL-Rollup](https://docs.ethhub.io/ethereum-roadmap/layer-2-scaling/zk-rollups/)
- [ZK-SNARKs](https://medium.com/coinmonks/zk-snarks-a-realistic-zero-knowledge-example-and-deep-dive-c5e6eaa7131c)
- [ZK-STARKs](https://medium.com/coinmonks/zk-starks-create-verifiable-trust-even-against-quantum-computers-dd9c6a2bb13d)
- [Snarks-vs-starks](https://www.alchemy.com/overviews/snarks-vs-starks)


This article provides an overview of zero-knowledge proofs in blockchain technology, including their definition, how they work, and their advantages.

Zero-knowledge proofs


![](assets/multisign-wallet-hero-image.webp)

## Intro multisig wallet

Usually, blockchain wallets are generally generated by a unique private key. All assets or transactions are controlled and signed by that private key. That key holder can do anything with that wallet. This is great for individuals, as it ensures privacy and security, as only the owner of the private key has full rights to those assets.

But with an organization, such as assets after IDO, private sale, or common company assets, it is different, if this asset is controlled by a single person, there will be a lot of risk. can happen like:

- This person took all the assets and disappeared.
- Due to some reason, this person loses the private key, then recovering the private key is not possible, which means that the entire property will also be inaccessible.
- If this person unfortunately dies, no one can inherit or use the property anymore because there is no private key.

To solve the above problems, **Multisig Wallet** was born to minimize those risks.

## What is multisig wallet?

In essence _Multisig Wallet_ is a **smart contract** on the blockchain that allows certain logic to be processed when there are **enough** required signatures.

> _Multisig_ is short for _Multi Signature_.

A _Multisig Wallet_ has the following properties:

- Parties agree on an action
- The rules in the smart contract have been built
- Smart contract can receive cryptocurrency (e.g. Ether)
- Smart contract can receive request, can be able to process that request based on consensus signing
- According to the multisig address configuration, it may require a different key combination: 2-of-3 is the most common key, where only 2 signatures are enough to access the funds of an address 3 signature. However, there are many other variations, such as 2 of 2, 3 of 3, 3 of 4, etc.

## How does it work?

As a simple analogy, we can picture a safe with two locks and two keys. One key is held by Alice and the other is held by Bob. The only way they can open the box is to provide both keys at the same time, so one cannot open the box without the other's consent.

Basically, funds stored on a multi-signature address can only be accessed using 2 or more signatures. Thus, using a multisig wallet allows users to create an extra layer of security for their funds. But before going any further, it is important to understand the basics of standard Bitcoin addresses, which are based on a single key rather than multiple (single key addresses).

## Pros and cons of multisig wallet

Everything has two sides, security and convenience are always two opposite sides of each other, so is Multisig Wallet.

### Advantages

- Higher level of safety for any web3 user.
- Multisig Wallet enhances the security of assets: For example, we can set up a multisig wallet for 3 accounts at 3 devices: phone, tablet, laptop. Each transaction can only be done when there is confirmation from 2 of those 3 devices. At this time, if we assume that we lose our phone, we can still confirm the transaction using tablets and laptops, while the thief cannot confirm the transaction with just one device.
- Multisig Wallet dispute resolution: An example is A and B buying and selling assets, they decide to use a 2-of-3 multisig wallet with the participation of 3 parties A, B, and ruling party C. In case A and B have signed _agree_ or _cancelled_, the participation of C will not be needed. Otherwise if only one sign _co-sign_, and the other person signs _cancellation_, then C's signature will decide whether the transaction will be _agreeed_ or _cancelled_ by a majority of 2 out of 3 decisions.
- Decision making: A board of directors might use a multisig wallet to control access to a company's funds. For example, by setting up a 4-of-6 wallet where each board member holds one key, no individual board member is able to misuse the funds. Therefore, only decisions that are agreed upon by the majority can be executed.

### Defect

- In the above example, suppose we need 3 devices to confirm the transaction, and we lose our phone? neither me nor the thief can confirm any more transactions? That's the downside of Multisig Wallet: the rules are too complicated to set up effectively for each specific problem.

> In this case, 2FA can be an effective solution to save the backup code for the account on the device, if we lose the device, we can still get the backup code back, which means getting the account back. .

- Both blockchain and multisig are still new technologies, the security audit is still limited. There is no 100% guarantee that what works today won't be hacked tomorrow. For example, the $300 million hack of Parity Wallet.
- More gas fee when you have to submit your signature to verify a request and deplay to making final transaction.
- Still limited action by smart contract operations.

## Build minimum multisig wallet

[Mutisig smart contract](https://solidity-by-example.org/app/multi-sig-wallet/):

```js
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.13;

contract MultiSigWallet {
  event Deposit(address indexed sender, uint amount, uint balance);
  event SubmitTransaction(
    address indexed owner,
    uint indexed txIndex,
    address indexed to,
    uint value,
    bytes data
  );
  event ConfirmTransaction(address indexed owner, uint indexed txIndex);
  event RevokeConfirmation(address indexed owner, uint indexed txIndex);
  event ExecuteTransaction(address indexed owner, uint indexed txIndex);

  address[] public owners;
  mapping(address => bool) public isOwner;
  uint public numConfirmationsRequired;

  struct Transaction {
    address to;
    uint value;
    bytes data;
    bool executed;
    uint numConfirmations;
  }

  // mapping from tx index => owner => bool
  mapping(uint => mapping(address => bool)) public isConfirmed;

  Transaction[] public transactions;

  modifier onlyOwner() {
    require(isOwner[msg.sender], "not owner");
    _;
  }

  modifier txExists(uint _txIndex) {
    require(_txIndex < transactions.length, "tx does not exist");
    _;
  }

  modifier notExecuted(uint _txIndex) {
    require(!transactions[_txIndex].executed, "tx already executed");
    _;
  }

  modifier notConfirmed(uint _txIndex) {
    require(!isConfirmed[_txIndex][msg.sender], "tx already confirmed");
    _;
  }

  constructor(address[] memory _owners, uint _numConfirmationsRequired) {
    require(_owners.length > 0, "owners required");
    require(
      _numConfirmationsRequired > 0 &&
        _numConfirmationsRequired <= _owners.length,
      "invalid number of required confirmations"
    );

    for (uint i = 0; i < _owners.length; i++) {
      address owner = _owners[i];

      require(owner != address(0), "invalid owner");
      require(!isOwner[owner], "owner not unique");

      isOwner[owner] = true;
      owners.push(owner);
    }

    numConfirmationsRequired = _numConfirmationsRequired;
  }

  receive() external payable {
    emit Deposit(msg.sender, msg.value, address(this).balance);
  }

  function submitTransaction(
    address _to,
    uint _value,
    bytes memory _data
  ) public onlyOwner {
    uint txIndex = transactions.length;

    transactions.push(
      Transaction({
        to: _to,
        value: _value,
        data: _data,
        executed: false,
        numConfirmations: 0
      })
    );

    emit SubmitTransaction(msg.sender, txIndex, _to, _value, _data);
  }

  function confirmTransaction(uint _txIndex)
    public
    onlyOwner
    txExists(_txIndex)
    notExecuted(_txIndex)
    notConfirmed(_txIndex)
  {
    Transaction storage transaction = transactions[_txIndex];
    transaction.numConfirmations += 1;
    isConfirmed[_txIndex][msg.sender] = true;

    emit ConfirmTransaction(msg.sender, _txIndex);
  }

  function executeTransaction(uint _txIndex)
    public
    onlyOwner
    txExists(_txIndex)
    notExecuted(_txIndex)
  {
    Transaction storage transaction = transactions[_txIndex];

    require(
      transaction.numConfirmations >= numConfirmationsRequired,
      "cannot execute tx"
    );

    transaction.executed = true;

    (bool success, ) = transaction.to.call{value: transaction.value}(
      transaction.data
    );
    require(success, "tx failed");

    emit ExecuteTransaction(msg.sender, _txIndex);
  }

  function revokeConfirmation(uint _txIndex)
    public
    onlyOwner
    txExists(_txIndex)
    notExecuted(_txIndex)
  {
    Transaction storage transaction = transactions[_txIndex];

    require(isConfirmed[_txIndex][msg.sender], "tx not confirmed");

    transaction.numConfirmations -= 1;
    isConfirmed[_txIndex][msg.sender] = false;

    emit RevokeConfirmation(msg.sender, _txIndex);
  }

  function getOwners() public view returns (address[] memory) {
    return owners;
  }

  function getTransactionCount() public view returns (uint) {
    return transactions.length;
  }

  function getTransaction(uint _txIndex)
    public
    view
    returns (
      address to,
      uint value,
      bytes memory data,
      bool executed,
      uint numConfirmations
    )
  {
    Transaction storage transaction = transactions[_txIndex];

    return (
      transaction.to,
      transaction.value,
      transaction.data,
      transaction.executed,
      transaction.numConfirmations
    );
  }
}
```

### Deployed multisig wallets

There is no universal standard for writing Multisig Wallet, but we can refer to the implementation from famous wallets being used in the world to be able to design or inherit our own implementation.

- [ConsenSys' multisig wallet](https://github.com/ConsenSys/MultiSigWallet): This can be considered the simplest implementation of Multisig Wallet, the solidity version used is also 0.4.10 a long time ago. , but is extremely valuable, at the time of writing this wallet is holding 80,000 Ether, or about 17 million dollars. You can look up this wallet [here](https://etherscan.io/address/0x851b7f3ab81bd8df354f0d7640efcd7288553419).
- [Gnosis' multisig wallet](https://github.com/Gnosis/MultiSigWallet): is an upgraded version of Consensys Multisig Wallet, written according to Truffle project's structure, fully tested and regularly updated. At the time of writing, this github project is still being updated.
- [Gnosis' multisig wallet](https://github.com/safe-global/safe-contracts): is an upgraded version of Consensys Multisig Wallet, written according to the structure of the hardhat project.
- [BitGo's multisig wallet](https://github.com/BitGo/eth-multisig-v2): also a structured version of Truffle, fully tested and regularly updated. The difference here is that the contract has more complex logic, one of which is ERC20-Token Compatibility. And this wallet implements 2-of-3 signing method, which means that there are exactly 3 parties involved, and 2 signatures are needed to agree for a transaction to take place.
- [Ethereum dapp's multisig wallet](https://github.com/ethereum/dapp-bin/blob/master/wallet/wallet.sol): Compatible with Ethereum Wallet or Mist, we can deploy Multisig Wallet here, and easily call `send transaction` or `confirm` directly. However, there is a disadvantage that there is no document, we have to read the code for more details.
- [Parity's multisig wallet](https://parity.io/) (NOT RECOMMENDED): This is also a very famous Multisig Wallet before it was [hacked and lost $300 million](https://medium.com /chain-cloud-company-blog/parity-multisig-hack-again-b46771eaa838) on 11/06/2017. The reason is because the implementation is not good, and therefore it is not recommended anymore.

## Referrence

- https://www.curvegrid.com/docs/multi-signature-multisig-wallet-smart-contracts
- https://www.binance.vision/security/what-is-a-multisig-wallet
- https://medium.com/hellogold/ethereum-multi-signature-wallets-77ab926ab63b
- https://www.gemini.com/cryptopedia/what-is-a-multi-sig-wallet-crypto-multi-signature-wallet


A multisign wallet is a type of digital wallet that requires multiple signatures to authorize transactions. This article provides an overview of multisign wallets, how they work, and their benefits.

Multisign wallet


This article features a short tutorial to start smart contract development on Solana using Anchor framework. Before you get started, we assume you already had the experience with:

- Basic knowledge of Solana network
- Concepts of: Account, program, instruction
- Knowledge of Rust or C++ language
- Install and launch local network Solana

### What is Anchor?

Anchor is a framework as well as a set of libraries that make developing applications on the Solana network faster and easier, However, you need to pay attention, the source code of the framework This has not been audited, please be careful when using. In addition, Anchor also provides a number of tools for developers.

- Rust crates and eDSL for writing Solana programs
- IDL specification
- TypeScript package for generating clients from IDL
- CLI command and workspace management for developing complete programs

### Why do we use Anchor?

- Easy to use library
- The ingredients are clear
- Many utilities for faster build, test and deploy
- Having IDL generate client on javascript or Golang easy

### Core components

An Anchor program consists of 3 main parts:

1. **Program**: where the logic of the program is stored
2. **Account struct**: where the account struct is defined, marked with `#[derive(Accounts)]`
3. **declare_id**: Declare the address of the program, it uses this id for security checks as well as allowing other programs to access your key field

Like other networks Solana also develops RPC, creating IDLs and client apps from IDL similar to ABI on Ethereum.

In the anchor you need to setup workspace for your project, example workspace for devnet

```
[provider]
cluster = "devnet"
wallet = "~/.config/solana/id.json"

[programs.devnet]
basic_0 = "2Fcoq3dKjpZiKko9Ho4NZguunJsd9AiGHheF8VHPnk7D"

[scripts]
test = "yarn run mocha -t 1000000 tests/"
```

If you want to deploy testnet, you need to move cluster to testnet, view cluster list:

```
anchor cluster list
```

#### Install Anchor and create a program:

Step 1. Install the library

- Rust

```curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
source $HOME/.cargo/env
rustup component add rustfmt
```

- Solana:

```
sh -c "$(curl -sSfL https://releases.solana.com/v1.9.1/install)"
```

- Yarn:

```
npm install -g yarn
```

- Anchor:

```
npm i -g @project-serum/anchor-cli
```

Check anchor install: anchor --version

Step 2: Create a program

```
anchor init <new-project-name>
```

Note, you need to choose the appropriate Anchor version for the sample project or you may get an error when building because the old versions are no longer compatible. Let's take the example of creating a program that accepts a key-value pair start with declaring the program you declare in the `lib.rs` directory

```
use anchor_lang::prelude::*;

declare_id!("Fg6PaFpoGXkYsidMpWTK6W2BeZ7FEfcYkg476zPFsLnS");

#[program]
mod basic_0 {
    use super::*;
    pub fn initialize(_ctx: Context<Initialize>) -> Result<()> {
        Ok(())
    }
}

#[derive(Accounts)]
pub struct Initialize {}
```

A smart contract program on Solana will have the following structure:

```
processor.rs
instruction.rs
errors.rs
state.rs
lib.rs
```

Next we will run the program build command:

```
anchor build
```

If you don't use the anchor, it will be equivalent to the command

```
cargo build-bpf
```

##### Note if you build error, you need to update anchor-lang to version 0.24.2

In addition, it will run additional commands to generate the IDL file

```
anchor idl parse -f program/src/lib.rs -o target/idl/basic_0.json.
```

Similar to Ethereum, you will build a target directory, in addition it will generate a target/idl/basic_0.json file, this file is similar to the ABI.json file. Note that the idl file will also be used to generate the client source code on JS and Golang

Next, we will deploy the program, notice that you need to select the environment to deploy via the command:

```
solana config set --url localhost
- devnet
solana config set --url devnet
- testnet
solana config set --url testnet
- Mainnet-beta
solana config set --url mainnet-beta
```

Command to deploy to the network:

```
anchor deploy
```

After running this command, your program has been deployed to the blockchain. You can continue to create transactions with it by creating a client.

build successfully, you will get a log that looks like this: To deploy this program run:

```
  $ solana program deploy /Volumes/WORKS/Dropbox/Blockchain/solana/SolTwit/target/deploy/sol_twit.so
```

#### Anchor CLI

```
USAGE:
    anchor <SUBCOMMAND>

FLAGS:
    -h, --help       Prints help information
    -V, --version    Prints version information

SUBCOMMANDS:
    build      Builds the workspace
    cluster    Cluster commands
    deploy     Deploys each program in the workspace
    expand     Expands the macros of a program or the workspace
    help       Prints this message or the help of the given subcommand(s)
    idl        Commands for interacting with interface definitions
    init       Initializes a workspace
    migrate    Runs the deploy migration script
    new        Creates a new program
    shell      Starts a node shell with an Anchor client setup according to the local config
    test       Runs integration tests against a localnetwork
    upgrade    Upgrades a single program. The configured wallet must be the upgrade authority
    verify     Verifies the on-chain bytecode matches the locally compiled artifact. Run this
               command inside a program subdirectory, i.e., in the dir containing the program's
               Cargo.toml
```

#### Anchor version manager

Anchor version manager (avm) is provided to manage multiple installations of the anchor-cli binary. This may be required to produce verifiable builds, or if you'd prefer to work with an alternate version. Like NVM, some command we should remember:

```
USAGE:
    avm <SUBCOMMAND>

OPTIONS:
    -h, --help       Print help information
    -V, --version    Print version information

SUBCOMMANDS:
    help         Print this message or the help of the given subcommand(s)
    install      Install a version of Anchor
    list         List available versions of Anchor
    uninstall    Uninstall a version of Anchor
    use          Use a specific version of Anchor
```

#### Basic concepts to know before starting development

- **Account**: A record in Solana Ledger to store information or a executable program, Save funds called lamports. expressed through an address by a key aka public key
- **Account owner**: The address of the program that owns the account. Only the owner program can edit the account
- **Block**: A block of data, continuously generated and covered by votes. Contains transaction information.
- **BPF loader**: The Solana program that owns and loads BPF smart contract programs, allowing the program to interface with the runtime.
- **keypair**: A public key and corresponding private key for accessing an account.
- **lamport**: A fractional native token with the value of 0.000000001 sol.
- **leader**: The role of a validator when it is appending entries to the ledger.
- **leader schedule**: A sequence of validator public keys mapped to slots. The cluster uses the leader schedule to determine which validator is the leader at any moment in time.

#### Example and template code

- https://github.com/thanhpn/solana-anchor-template

### Reference

- https://docs.rs/anchor-lang/latest/anchor_lang/accounts/account/struct.Account.html
- https://book.anchor-lang.com/introduction/what_is_anchor.html
- https://www.rust-lang.org
- https://docs.rs/solana/latest/solana/


A comprehensive guide to getting started with smart contract development on Solana using the Anchor framework. This tutorial covers the basics of Anchor, its components, installation process, and provides step-by-step instructions for creating and deploying a simple program.

Anchor framework


![](assets/blockchain-bridge_blockruption-blockchain-300h.webp)

Web3 or Dapp has evolved into an ecosystem of L1 blockchains and L2 scaling solutions, each designed with unique tradeoffs and processing capabilities. As the number of blockchain protocols or applications increases rapidly, so does the need to move assets across chains. To meet this need, we need communication channels between chains that are bridges.

## What is a bridge?

Blockchain bridges work just like a physical bridge connecting two physical locations, a blockchain bridge connecting two blockchain ecosystems. Bridges facilitate communication between blockchains through the transfer of message and assets.

![](assets/blockchain-bridge.webp)

## Why do we need bridges?

All blockchains have their limits. In order for Ethereum to scale and keep up with demand, it needs to have rollouts. In addition, L1s such as Solana and Avalanche are designed differently to allow higher throughput but at the expense of decentralization.

However, all blockchains operate in an isolated environment and have different rules and consensus mechanisms. This means that they cannot communicate natively and tokens cannot move freely between blockchains (Networks can only send messages in one direction so it will not be able to talk to the other network directly). Bridges born to connect blockchains, allowing for the trustless transfer of message and tokens between them. Bridges need an authentication mechanism, so there are different types of bridges.

![](assets/blockchain-bridge_offchain-actors.webp)

## Bridge use-case?

- Transfer of assets and message across the chains
- Lower transaction fees
- Dapps on other blockchains
- Explore the blockchain ecosystem, users access new platforms and take advantage of different chains.
- Developers from different blockchain ecosystems to collaborate and build new platforms for users.
- Own natural crypto assets

![](assets/blockchain-bridge_bridge-use-cases.webp)

## How does the bridge work?

Basically a bridge works between 2 networks by listening for events arising from one network and forwarding information to the other network. So the basic problem is in the mechanism to ensure safety when forwarding information as well as message authentication and message monitoring.

### What are bridge components?

- Monitor: There is usually an actor, either a “oracle”, a “validator” or a “relayer”, that monitors the state on the source chain.
- Message Passing/Forwarding: After an agent selects an event, it needs to pass information from the source chain to the destination chain.
- Consensus: In some models, consensus is required between the parties monitoring the source chain to forward that information to the destination chain.
- Signing: Agents need to cryptographically sign, individually or as part of a threshold signature scheme, the information sent to the destination chain.

## Classification of bridges

![](assets/blockchain-bridge_classify-bridge.webp)

### External links & validators

There is usually a group of validators that monitor the "mailbox" address on the source chain, by consensus perform an action on the destination chain. Content transfer is usually done by locking the message in the mailbox and generating an equivalent message on the destination thread. These are usually bonded validators with a separate token as the security model.

![](assets/blockchain-bridge-external-links.webp)

### Lightweight client & relays

Agents monitor events on the source chain and generate cryptographic proof of past events that have been recorded on that chain. These proofs are then relayed, along with block headers, to contracts (i.e. "clients") on the target chain, which then verify that a given event was logged and executed. perform an action after that verification. There is a requirement for some actors to "forward" block headers and proofs. Although users can “self-forward” transactions, there is a realistic assumption that forwarders will continuously forward data. This is a relatively secure bridge design because it ensures trustless validating distribution without trusting intermediate entities, but it is also resource intensive because developers have to build build a new smart contract on each new destination chain that parses the proofs of state from the source chain and the confirmation itself is a lot of gas.

![](assets/blockchain-bridge_lightweight-client-relays.webp)

### Liquidity network

This is similar to a peer-to-peer network where each node acts as a “router” containing a “store” of assets of both the source and destination chains. These networks typically leverage the security of the underlying blockchain; Through the use of locking and contention mechanisms, users are assured that routers cannot run away with user funds. As a result, liquidity networks like Connext may be a safer option for users who are transferring large amounts of value. Furthermore, this type of bridge may be most suitable for cross-chain asset transfers because the assets provided by the router are the origin of the destination chain and not a derivative, which are not fully interchangeable.

## Depending on the design, each bridge will have its own characteristics

Security: Assumptions about reliability and viability, tolerance to malicious actors, safety of user funds, and reflectiveness.

- Speed: Latency to complete the transaction, as well as ensuring finality. There is usually a trade-off between speed and security.
- Connectivity: Choice of target chain for both users and developers, as well as different difficulty levels to integrate one more target chain.
- Efficient use of capital: Economics revolves around the capital needed to secure the system and the transaction costs to transfer assets.
- Authenticity: Ability to transfer specific assets, more complex state, and/or make cross-chain contract calls.

## Interoperability dilemma

![](assets/blockchain-bridge_interoperability-dilemma.webp)

Similar to Trilemma in terms of scalability, there exists a Trilemma of interoperability in the Ethereum ecosystem. The Interop protocol can only have two of the following three properties:

- Untrusted: has the same security as basic domains.
- Scalability: can be supported on any domain.
- Generalizability: capable of handling arbitrary cross-domain data.

## Risks of using bridge

- There is a bug in the smart contract.
- The underlying blockchain is hacked or the block is rolledback: The data of a block is preserved in one chain but cannot be changed in the other chain.
- Bridge moderators have malicious intent in a trusted bridge.
- Hacked bridge: attack via internal consensus mechanism.
- The user makes a mistake when manipulating.
- Congested or hacked chains will affect bridging.

![](assets/blockchain-bridge_lock-mint-and-burn.webp)

One recent hack was Solana's Wormhole Bridge, where 120k wETH ($325 million USD) was stolen in the hack. And Vitalik himself must have a reputation for the lack of safety of the bridges.

- [The multiple million exploit](https://decrypt.co/76117/thorchains-rune-token-slides-following-multi-million-exploit)
- [Thorchain hacks](https://www.coindesk.com/markets/2021/07/23/blockchain-protocol-thorchain-suffers-8m-hack/).
- [The PolyNetwork hack](https://edition.cnn.com/2021/08/11/tech/crypto-hack/index.html).

## Case study

- One of our product - [icrosschain.io](https://icrosschain.io/)
- Wormhole
- Thorchain

## Reference

- https://en.wikipedia.org/wiki/Ethereum
- [What are blockchain bridges and how can we classify them?](https://blog.li.finance/what-are-blockchain-bridges-and-how-can-we-classify-them-560dc6ec05fa) Feb 18, 2021 - Arjun Chand
- [Multichain users lose (https://cryptobriefing.com/multichain-users-lose-1-4m-due-bridge-bug/).4M due to bridge bug](https://cryptobriefing.com/multichain-users-lose-1-4m-due-bridge-bug/)
- [Vitalik Buterin skeptical of cross-chain bridges](https://cryptobriefing.com/vitalik-buterin-skeptical-of-cross-chain-bridges/)
- [Latest DeFi bridge exploit results in $4.4M losses for Meter](https://cointelegraph.com/news/latest-defi-bridge-exploit-results-in-4-4m-losses-for-meter)


A comprehensive guide to understanding blockchain bridges, their types, and how they facilitate communication and asset transfers between different blockchain networks.

Blockchain bridge


## Blocks

![](assets/blocks_lzrylgx.webp)

### 1. Define block in the blockchain

A block is thus a permanent store of records that, once written, cannot be altered or removed. A Block has a limited size and transaction to avoid All Block are verified on the blockchain by all nodes and stored on the blockchain Block data are batches of transactions with a hash of the previous block in the chain. This links blocks together (in a chain) because hashes are cryptographically derived from the block data. This prevents fraud, because one change in any block in history would invalidate all the following blocks as all subsequent hashes would change and everyone running the blockchain would notice.

![](assets/blocks_svihd1p.webp)

### 2. Block data

#### 2.1 Standard data

- Block height – The block number and length of the blockchain (in blocks) on creation of the current block.
- Timestamp – The time at which a miner mined the block.
- Transactions – The number of transactions included within the block.
- Miner – The address of the miner who mined the block.
- Reward – The amount of ETH awarded to the miner for adding the block (standard 2ETH reward + any transaction fees of transactions included in the block).
- Difficulty – The difficulty associated with mining the block.
- Size – The size of the data within the block (measured in bytes).
- Gas used – The total units of gas used by the transactions in the block.
- Gas limit – The total gas limits set by the transactions in the block.
- Extra data – Any extra data the miner has included in the block.

#### 2.2 Advanced data

- Hash - The cryptographic hash that represents the block header (the unique identifier of the block).
- Parent hash – The hash of the block that came before the current block.
- Sha3Uncles – The combined hash of all uncles for a given parent.
- StateRoot – The root hash of Merkle trie which stores the entire state of the system.
- Nonce – A value used to demonstrate proof-of-work for a block by the miner.

#### 2.3 Uncle blocks

Uncle blocks are created when two miners create blocks at near-enough the same time – only one block can be validated across the nodes. They are not included but still receive a reward for the work.

Block explorers provide information about uncle blocks like:

- An uncle block number.
- A time they occurred.
- The block height at which they were created.
- Who mined it.
- The ETH reward.

![](assets/blocks_eqhpghw.webp)

### 3. block time

Block time refers to the time it takes to mine a new block. In Ethereum, the average block time is between 12 to 14 seconds and is evaluated after each block. The expected block time is set as a constant at the protocol level and is used to protect the network's security when the miners add more computational power. The average block time gets compared with the expected block time, and if the average block time is higher, then the difficulty is decreased in the block header. If the average block time is smaller, then the difficulty in the block header will be increased.

A new block can be rejected, please be careful with the new block, You need to wait for maximum node to verify this block before use.

### 4. block size

A final important note is that blocks themselves are bounded in size. Each block has a target size of 15 million gas but the size of blocks will increase or decrease in accordance with network demands, up until the block limit of 30 million gas (2x target block size). The total amount of gas extended by all transactions in the block must be less than the block gas limit. This is important because it ensures that blocks can’t be arbitrarily large. If blocks could be arbitrarily large, then less performant full nodes would stop being able to keep up with the network due to space and speed requirements.

### 5. mining's relationship to blocks

Mining is the term used for solving the number that is the nonce, the only number that can be changed in a block header. It is also the process the cryptocurrency's network uses if proof-of-work is used in the protocol.

![](assets/blocks_qi5jtrdpng.webp)

Cryptocurrency mining is commonly thought to be a complex mathematical problem; it is actually a random number generated through hashing. Hashing is the process of encrypting information using the encryption method a cryptocurrency uses. For example, Bitcoin uses SHA256 for its encryption algorithm. For a miner to generate the "winning" number, the mining program must use SHA 256 to hash random numbers and place them into the nonce to see if it is a match.

### 6 Gas in block

Gas is used to estimate the difficulty of all transactions in the block. Every function in a smart contract or transaction on blockchain will pay gas to process. To submit a transaction and avoid miners delaying your transaction forever, you need to pay enough gas Gas = Gas used \* Gas ​​price

#### Reference

https://ethereum.org/en/developers/docs/blocks/


This article provides an overview of blocks in blockchain technology, including their structure, types, and how they work.

Blocks


![](assets/blockchain-bridge_blockruption-blockchain-300h.webp)

## Distributed systems on blockchain

As defined on Wiki, distributed computing is a branch of computer science that studies distributed systems. A distributed system is a software system whose components are located on different computers, connected in a network. These computers work together as a single entity to accomplish a common task by exchanging messages. Distributed computing is decentralized parallel computing. The types of hardware, programming languages, operating systems, and other resources used can vary widely. It is similar to computer clustering with the main difference being the geographical distribution of resources.

Distributed systems appear to be very common in practice. Most applications today, especially Internet applications, are implemented as Distributed systems. Deploying software, especially large systems, on multiple computing units (instead of using a single computer) has many benefits, such as:

- Provide more resources when the system needs to handle a larger amount of work.
- Using only one computer unit means the risk of software crashing (crash) if that machine has a problem. Using multiple machine units will allow you to continue operating the software even if problems occur.
- When your system becomes complex and requires the combination of many different components, using DS allows you to break down a large system into many small units. Each unit can operate independently, can even be developed by different teams with different expertise.

System users may be geographically dispersed across the globe. To ensure quality of service and limit latency, the machine system also needs to be distributed so that it can be as close to the user as possible.

## Advantages of distributed systems:

- Scalability: There are two types of scaling: horizontal scaling and vertical scaling:
- Reliability: Reliability is the fault tolerance of the system which means that the system will continue to provide its service as soon as one or more components (software/hardware) of the system fail.
- Availability: is the total time a system remains in normal operation for a specific period of time. A measure of availability is the percentage of time the system is up and running continuously for a period of time (usually 1 year).
- Efficiency: The efficiency of a distributed system is high load and low latency. This means that a system that can handle many concurrent requests with low latency is a high-performance system.
- Manageability: it is the ability to easily expand and maintain the system. In other words, it is the time to perform repair (repair) or maintain (maintain) when needed, the higher the time, the lower the availability.

## Machine failure (node failure)

Each physical computer, due to various reasons, can experience problems while in operation. These incidents are divided into several main categories:

- Fail-stop: This is a type of problem that causes the process on the machine to stop working (stops computation as well as communication). The cause of this problem can be due to the machine crashing (software error, operating system error ...), hardware failure, or external causes (eg power failure). This is the most common type of problem, so when people talk about 'failure' without saying anything else, it's usually implied as this type of problem. Most of the algorithms developed in DS are intended to deal with this type of problem.
- Fail-recover: Process may be down for a certain time, but then recovery works again. The cause of this type of problem can be due to the machine rebooting automatically for some reason. Often when talking about this type of failure, people assume that the machine has the ability to store information on the hard drive and recover this information after the failure occurs.
- Byzantine failure: The problem that the computer does not work according to the requirements set forth. For example, the machine can send arbitrary messages, or change state arbitrarily, unlike what is programmed. This is the most annoying type of problem, which can happen when the system crashes for no apparent reason (e.g. RAM may be damaged causing bit-flip), or because the system is attacked by malicious actors. .

## Network problems

A computer network is also a physical product and so problems can also occur. A common type of problem is the “network partitioning” problem, which is simulated by the figure above. This problem occurs when the transmission of one or more servers is cut off from the rest of the system, causing the system to be split into many parts that cannot communicate with each other. In fact, in data centers, a cluster of servers is usually connected by one or more switches. Failure of the switch port or wire can lead to one or more servers being disconnected, leading to the aforementioned partitioning situation.

## Distributed systems in blockchain

![](assets/distributed-systems_c7xyhh1.webp) Blockchain is a distributed ledger, which simply means that a ledger is spread across the network among all peers (nodes) in the network. Every node has a copy of the Blockchain and once a block reaches a certain number of approved transactions then a new block is formed

Any computer can join the blockchain network and become a validator by connecting to the internet and launching applications. The difference is that to become a node on the network, a computer needs to meet certain requirements in terms of connection speed, storage speed, and storage space. For the current bitcoin network, due to too many miners participating in the operation, the network requires a huge amount of computing power, If you want to participate in the network you need to run the service through the mines to contribute strength.

## Distributed software on blockchain

"The Ethereum Virtual Machine (EVM) is the runtime environment for transaction execution in Ethereum. It includes a stack, memory, gas balance (see below), program counter, and the persistent storage for all accounts (including contract code). When a transaction calls a contract's function, the arguments in the call are added to the stack and the EVM translates the contract's bytecode into stack operations. Stack items may be stored in memory or storage, and data from memory/storage may be added to the stack. The EVM is isolated from the other files and processes on the node's computer to ensure that for a given pre-transaction state and transaction, every node produces the same post-transaction state, thus enabling network consensus such as PoS. The formal definition of the EVM is specified in the Ethereum Yellow Paper. EVMs have been implemented in C++, C#, Go, Haskell, Java, JavaScript, Python, Ruby, Rust, Elixir, Erlang, and soon WebAssembly."

The EVM's instruction set is Turing-complete. Popular uses of Ethereum have included the creation of fungible (ERC20) and non-fungible (ERC721) tokens with a variety of properties, crowdfunding (e.g. initial coin offerings), decentralized finance, decentralized exchanges, decentralized autonomous organizations (DAOs), games, prediction markets, and gambling.

## How about scale for blockchain ?

Concerning pure computing power, distributed computing offers easier scalability than centralized computing. It's relatively easy to add more machines to gain more computing power and reduce them when power needs are lower.

However, blockchain has different scalability issues. In a blockchain, the number of transactions processed in a fixed period limits transaction speed. Therefore, the scalability issue is one of transaction speed. This scalability limitation is due to the need for the nodes in a blockchain to reach consensus on the transactions taking place. Therefore, while distributed computing itself offers a high degree of scalability, the game theory element of blockchain is generally what hampers scalability on transaction speeds.

This gives rise to a concept of difficulty, Once there are too many computers involved in processing the transaction. The network will change the difficulty to reduce contention. The computer will have to calculate with higher difficulty.

The downside is that performance issues arise because every node calculates all the smart contracts in real-time. As of January 2016, the Ethereum protocol could process about 25 transactions per second. In comparison, the Visa payment platform processes 45,000 payments per second. The next Ethereum 2.0 can serve more than 100.000 transactions

Today we have a series of solutions to improve transaction speed on ethereum such as: Layer 2.

## Reference

https://en.wikipedia.org/wiki/Ethereum https://www.youtube.com/user/cbcolohan https://www.worldbank.org/en/topic/financialsector/brief/blockchain-dlt https://en.wikipedia.org/wiki/Distributed_ledger https://www.youtube.com/playlist?list=PLrw6a1wE39_tb2fErI4-WkMbsvGQk9_UB


This article provides an overview of distributed systems in blockchain technology, including their definition, advantages, and how they work.

Distributed systems


## The proof of stake

The proof of stake consensus algorithm was introduced in 2011 on the Bitcointalk forum to solve the problems of the most popular algorithm in use – Proof of Work. . While both share the same goal of achieving consensus in the blockchain, the process to achieve the goal is quite different. where the nodes of a blockchain-based network must "stake" a sum of money or tokens (proving their identity) in order to participate in the verification of transactions in a block.

Just like proof of work, proof of stake is designed to achieve distributed consensus on the valid order of transactions - i.e. reach agreement on a single shared version of history .

PoS indicates that a person can mine or confirm block transactions according to the amount of coins he or she holds. This means that the more Bitcoins or tokens owned by a miner, the more mining power will be available.

The first cryptocurrency to adopt the PoS method was Peercoin. Nxt, Blackcoin and then ShadowCoin.

![](assets/pos_jouvtnmpng.webp)

## How proof of stake works

The proof of stake algorithm uses a pseudo-random election process to select a node as the validator of the next block, based on a combination of factors that may include staking age, random and the size of the button. Users who wish to participate in this process must lock a certain number of native tokens into the network as their stake. The size of the stake determines the chance for a node to be selected as a validator to generate the next block – the larger the stake, the greater the chance. In order for the process not only to prioritize the wealthiest nodes in the network, unique methods are added to the selection process. The two most commonly used methods are 'Random Block Selection' and 'Coin Age Selection'. In the Random Block Pick method, validators are selected by looking for nodes with the combination of the lowest hash value and the highest stake, and since the stake size is public, the validator node The next real thing can usually be predicted by other nodes. The Coin Age Selection method selects nodes based on how long their coins have been staked. Coin age is calculated by multiplying the number of days the coin is held by the number of coins staked. When a node forges a block, their coin age is reset to zero and they have to wait a certain amount of time before they can generate another block – this prevents large stake nodes from dominating the blockchain.

Each native token that uses the Proof of Stake algorithm has its own set of rules and methods to create the best combination for them and their users.

When a node is selected to generate the next block, it checks if the transactions in the block are valid, signs the block, and adds it to the blockchain. The node receives the transaction fees associated with the transactions in the block.

If a node wants to stop working as a blacksmith, its staked coins along with the rewards earned are released after a certain amount of time, giving the network time to verify that no fraudulent blocks were added by that node. into the blockchain.

Proof of stake was created as an alternative to proof of work (PoW), to solve the inherent problems of computation time and energy consumption when using PoW.

PoS seeks to solve the problem by reducing mining power to the percentage of coins a miner spends to join the nodes. This way, instead of using energy to solve the PoW problem, PoS miners are limited to mining by a transaction rate that reflects the number of shares the miner owns. For example, a miner who owns 3% of Bitcoins could theoretically only mine 3% of those blocks.

#### Compare PoW and PoS

![](assets/pos_xiuwh4mpng.webp)

## About security

The stake coin acts as a financial incentive for the forging node to not validate or generate fraudulent transactions. If the network detects a fraudulent transaction, the forging node will lose part of its stake and the right to participate in future block forging. So as long as the stake is higher than the reward, validators will lose more coins than they would have gained in case of a fraud attempt.

To effectively control the network and approve fraudulent transactions, a node would have to own a majority stake in the network, this is known as a 51% attack. Depending on the value of the native token, this would be very impractical as to gain control of the network you would need to have more than 51% of the circulating supply.

In 2017, Ethereum (ETH) started its full transition from PoW to PoS system and by 2022 it has successfully deployed on Ropsten testnet.

## Advantages of PoS:

- Fast transaction processing.
- PoS does not harm the environment.
- Not vulnerable to government attacks: don't need huge amounts of electricity.
- Can be performed on smaller and weaker devices because there is no need to download the entire blockchain, and because it does not require a lot of computing power, it can be


This article provides an overview of Proof of Stake (PoS) in blockchain technology, including its definition, how it works, and its advantages.


## Smart contracts

Smart contracts, also known as smart contracts, are computer programs that operate on the blockchain. Entities interacting with the contract do not need to know each other or trust each other.

- The contract ensures that with the conditions of the contract satisfied, the contract will be executed
- The logic of the contract can be verified. In other words, a smart contract is an intermediary, greatly reducing operating costs if you do it in real life: for example, if you buy a house, you must notarize it, then pay. money at the notary office, then go to the real estate office to do the account transfer procedure... it will need many steps involving people and intermediaries. If you make this purchase on a smart contract, you will simply create a home sale transaction and one buyer will create a purchase transaction, the other contract will perform the transfer of money, change ownership, related information, and sales history.

## How smart contract work:

- Developer distributes contract on the blockchain
- The user signs the transaction and invokes the contract on the blockchain
- Contract processes data and executes commands
- The data after being executed will be saved on the blockchain

## Structure of a smart contract:

- Declare solidity version
- Declare libraries, interfaces
- Declare variables
- Declare constructor
- Processing instructions
- Save state
- Event/Log

Declare variable

Function/Instruction

Event/Log

## Invoke another smart contract:

Currently, Ethereum there are many contracts such as tokens, NFT-ERC721, games, swaps, lending... To work directly with these contracts you can make calls directly from your application from javascript or go lang via ABI, ABI is an interface type similar to API specification file or description file. describe swagger. It defines data objects and callable functions. Or you can also call the interface of another contract in your contract for example:

- Declare interface
- Call command

## The advantages of smart contracts:

- Efficiency: Smart contracts promise to automate business processes at a corporate level. This reduces operating costs and saves resources, including the staff needed to oversee complex operations involving multiple companies.
- Processing speed: Smart contracts help improve the processing speed of processes between many different companies and corporations.
- Autonomy: Smart contracts are executed automatically by a network and help reduce the need for a 3rd party to manage transactions between companies.
- Reliability: Smart contracts also leverage blockchain ledger and other distributed ledger technologies to store all the information and operations involved in complex processing after it has been executed presently. This technology also supports automated trading which eliminates human errors and ensures accuracy in contract execution.

## The limitations of smart contracts:

- Security issues: Smart contracts play certain important roles in a business involving many parties. However, this technology is still new and hackers are constantly exploiting new attack directions to penetrate. In the early days of Ethereum, hackers hacked and stole a large amount of virtual currency worth $50 million. The IEEE Consortium of Electrical and Electronic Engineers has also expressed concern about the weakness of the tools used to detect vulnerabilities in smart contracts.
- Integrity: An oracle (a data source that sends event updates) should be protected from hackers creating fake events to trigger the processing of contracts even though they are not allowed. The system needs to be programmed to generate the correct events, which can be quite difficult in complex cases.
- Relevancy: Smart contracts can speed up processing in a multi-party contract regardless of whether it matches the intent or understanding of all parties. But it can also add to the damage in the event things get out of hand, especially when there's no way to stop or reverse the unintended actions. Research firm Gartner has pointed out that this creates a challenge in the management of smart contracts, although this challenge has not been fully addressed.
- Complexity in management: Smart contracts are quite complicated in deployment and management. They are often designed in such a way that it is very difficult or impossible to change. Although this increases security, the parties will not be able to change the content or add new terms without creating a new contract.

Take for example a smart contract when deployed When a Decentralized Autonomous Organization (DAO) named "The DAO" was hacked in 2016, millions of ETH were stolen due to a mistake in their smart contract code. Since their Smart contract is immutable, developers cannot edit the code. This eventually led to a hard fork, creating Ethereum Classic and Ethereum.

#### Reference

https://ethereum.org/vi/developers/docs/smart-contracts/


This article provides an overview of smart contracts in blockchain technology, including their definition, how they work, and their advantages.