-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Co-authored-by: Andrea Tarricone <[email protected]> Co-authored-by: Simone Sestito <[email protected]> Signed-off-by: Simone Sestito <[email protected]>
- Loading branch information
1 parent
31a5d96
commit 1acba90
Showing
31 changed files
with
1,387 additions
and
0 deletions.
There are no files selected for viewing
Binary file not shown.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,70 @@ | ||
\documentclass[main.tex]{subfiles} | ||
|
||
\begin{document} | ||
|
||
\section{Background}\label{sec:background} | ||
\subsection{Blockchain's history} | ||
The first decentralized blockchain was conceptualized in 2008, year of the publication of the Bitcoin white paper by an unknown person or group using the pseudonym Satoshi Nakamoto\cite{nakamoto2009bitcoin}. The Bitcoin network officially came into existence on January 3, 2009, with the mining of the first block, known as the "Genesis Block." This marked the beginning of the Bitcoin blockchain. \\ | ||
Ethereum, conceived by Vitalik Buterin \cite{Vitalik:2014}, aimed to expand blockchain's capabilities beyond currency. | ||
The Ethereum blockchain went live on July 30, 2015, with its first version, Homestead. Ethereum introduced "smart contracts," enabling developers to create decentralized applications (DApps) on its platform. | ||
|
||
\subsection{How the blockchain works} | ||
The blockchain is a shared and an immutable ledger that contains transactions. The principal components are: | ||
\begin{itemize} | ||
\item Nodes - participants in the blockchain that through the accounts (Externally owned accounts) can make transactions and with a consensus mechanism can propose a block (miners). | ||
\item Transactions are the build-in blocks of a ledger and represent the transfer of an asset between accounts. | ||
\item Blocks are the structures that contain transactions and other useful fields like the header or the hash to the previous block. | ||
\end{itemize} | ||
|
||
% Once a transaction is considered valid, it cannot change as a consequence of staying in the ledger, because a change to them would cause a change in the block and so implicity would invalidate the next blocks which are chained through the hash. So an attacker that would change a transaction should have so much power to recostruct the other blocks which is considered infeasible. | ||
% \subsection{Types of blockchain} | ||
% A blockchain can be classified based on his transactability/visibility and the level of access control to consensus. According to the first one a blockchain can be divided in: | ||
% \begin{itemize} | ||
% \item private: In a private blockchain only selected nodes can transact and view. | ||
% \item public: In a public blockchain anyone can transact and view. | ||
% \end{itemize} | ||
% According to the second one the blockchain can be classified in: | ||
% \begin{itemize} | ||
% \item permissionless: All node can partecipate to consensus. | ||
% \item permissioned: selected nodes can partecipate to consensus. | ||
% \end{itemize} | ||
\subsection{Consensus algorithms} | ||
The aim of consensus algorithms is to reach an agreement through the participants of the blockchain. | ||
Given that blockchain is inherently decentralized, it requires a secure mechanism to achieve consensus on determining the latest block (implicitly to the previous ones because the hash of the previous block inside to a field of the header) and the correctness of the transactions inside the block. | ||
Different types of mechanisms to reach consensus have been proposed: | ||
\begin{itemize} | ||
\item \textbf{Proof of Work}: POW is a puzzle miners have to solve to gain the authority to publish a block by finding a nonce that results in a block hash below a difficulty threshold. POW can be solved by different miners at the same time so there can be forks, but the most computational work chain is the one considered valid. | ||
For this reason, a block is considered finalized after another 5 blocks. A miner who solves POW gains a price, which is currently bitcoin plus the transaction fee in the block. | ||
\item \textbf{Proof\ of\ Stake}: In POS the validators are not miners, but they stake a capital of 32 Ethereum(ETH). | ||
In Ethereum Proof of Stake, the tempo is fixed. | ||
Each epoch is composed by 32 slots and each slot lasts 12 seconds: 6 seconds for block proposal and 6 seconds for block attestations. In each slot, a commit of 128 validators is randomly chosen and one, from them, is randomly selected to be a block proposer and has 6 seconds to forge a new block. | ||
Validators vote on checkpoint pairs, justifying the most recent checkpoint with 2/3 of total staked ETH votes, finalizing the oldest justified checkpoint, and employing a sync committee every 256 epochs for block validation. | ||
Like in POW, validators can have different views of the head of the chain. To solve this problem POS uses \texttt{LMD-GHOST} algorithm, which chooses as the "right" one, the one that has the \textbf{greatest accumulated weight of attestations}. | ||
POS introduces slashing mechanisms to deter dishonest behaviors, including double proposals, FFG double votes, and attesters signing a checkpoint attestation that “surrounds” another one. | ||
\end{itemize} | ||
|
||
\subsection{Smart Contracts} | ||
Smart contracts are pieces of code that run on the blockchain. As transactions, once posted on the blockchain, their code runs uncensorably and cannot be changed. For this reason, they are considered trustworthy and secure, so participants in a smart contract do not need to trust each other or a third party. | ||
Smart contracts run on the Ethereum Virtual Machine and they are not for free. Every single bit or execution has a cost in terms of gas.\\ | ||
ERC are standards for smart contracts, so they are guidelines for programming on blockchain. | ||
\subsubsection{ERC-20} | ||
ERC-20\cite{ft} is the standard used to represent fungible tokens, meaning that \texttt{each token is identical} and can be exchanged on a one-to-one basis with any other token of the same type. | ||
These tokens are typically used to represent units of a certain resource, like coins used for accessing features or loyalty points. | ||
\subsubsection{ERC-721} | ||
ERC721 is the standard used to represent non-fungible tokens\cite{nft}. Unlike ERC-20 tokens, they are not interchangeable on a one-to-one basis. Each ERC-721 token is distinct and possesses unique characteristics, making them ideal for representing ownership of unique items. | ||
They cannot be divided into smaller units like fungible tokens so they are traded as whole units. | ||
\subsubsection{ERC-1155} | ||
ERC1155\cite{ERC-1155} is the combination of ERC-20 and ERC-721, so it allows the management of both fungible and non-fungible tokens within a single contract. These tokens are very useful in DApps that use batch operations, which are more efficient than operations on a single token. | ||
|
||
\subsection{IPFS and TOR} | ||
IPFS is a distributed file system designed to create a more efficient and resilient way of storing and sharing content on the internet.\cite{IPFS_Benet_paper_2014} The IPFS system associates a link to the files stored.\\ | ||
TOR is a privacy-focused network that aims to enhance anonymity and security for users on the internet. | ||
To access websites with ".onion" domains, users need to use the Tor browser, which is designed to connect to the Tor network. This browser allows users to navigate and access content within the Tor ecosystem. \cite{Tor_v2} | ||
|
||
\subsection{Encodings} | ||
Encoding is the process of converting data from one form to another, typically for the purpose of efficient storage, transmission, or representation. Some time happen that an encoding such as base64 is not efficient for the aim of the DApp, so finding one is crucial to reduce the amount of data and their cost. | ||
|
||
\subsection{Huffman Tree} \label{sec:introduction_huffman} | ||
Huffman coding is a compression algorithm that assigns variable-length codes to input characters, with shorter codes assigned to more frequently occurring characters. The algorithm begins by analyzing the frequency of each character in the input data (e.g., a text file). The algorithm builds a binary tree known as the Huffman tree. Each leaf node of the tree represents a character along with its frequency. Starting from the root of the tree, traversing left and right corresponds to adding '0' or '1' to the code. The codes assigned to the characters are determined by the path from the root to the respective leaf nodes. The original data is then encoded using the generated Huffman codes. The resulting compressed data typically occupies fewer bits than the original data, especially if there are frequently occurring characters. To decode the data the code itself is used, crossing through the nodes up to the character's leaf associated.\cite{Huffman_coding} | ||
|
||
\end{document} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,14 @@ | ||
\documentclass[main.tex]{subfiles} | ||
|
||
\begin{document} | ||
|
||
\section{Conclusions}\label{sec:conclusions} | ||
Finally, we are aware that our success is closely linked to the growth of the blockchain and web3 industry. We hope that the evolution of decentralized technologies will advance rapidly, thus helping to eliminate current barriers and facilitate a seamless transition to a more decentralized and inclusive digital landscape. | ||
|
||
GethDomains, like Dapp at the forefront, is a tangible example of how the mission of simplifying the interaction with resources on decentralized systems can be realized in a concrete way. By allowing users to autonomously manage their domains on Ethereum, the platform promotes a user-centered vision, highlighting the fundamental concept of decentralization. | ||
|
||
Through the architecture of the Ethereum blockchain, GethDomains provides an environment in which the user has complete control over their domains, ensuring unprecedented freedom in the use of digital resources. This approach eliminates the risk of censorship and reduces dependence on third parties, transforming the user into an autonomous actor within the decentralized ecosystem. | ||
|
||
|
||
|
||
\end{document} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,76 @@ | ||
\documentclass[main.tex]{subfiles} | ||
|
||
\begin{document} | ||
|
||
\section{Motion Equation} | ||
\label{sec:motion-equation} | ||
Consider a variable length pendulum (VLP) as shown in Fig. \ref{vlp} and assume the following properties in order to define the equations of motion of the system | ||
|
||
\begin{enumerate} | ||
\item the friction at the pivot $O$ and the viscous friction of the rod are considered absent | ||
\item the angle $\theta(t)$ to be between the pendulum and the vertical axis | ||
\item the length of the pendulum $l(t)$ that starts from the origin $O$ to the mass of the pendulum $m$ | ||
\item the rod is considered massless | ||
\item $f(t)$ is the force acting on the mass | ||
\end{enumerate} | ||
\begin{figure}[H] | ||
\centering | ||
\includegraphics[scale = 0.5]{figures/pendulum.png} | ||
\caption{Variable Length Pendulum \cite{xin2014control}} | ||
\label{vlp} | ||
\end{figure} | ||
Since the rod is massless, the position coordinates $(x_G,y_G)$ | ||
of the COM of the VLP is defined such that | ||
\begin{eqnarray} | ||
x_G = l(t)\sin\theta(t) & y_G = -l(t)\cos\theta(t) | ||
\end{eqnarray} | ||
The kinetic energy $T$ of the VLP is defined as | ||
\begin{equation} | ||
T = \frac{1}{2}m(\dot{x}_G^2+\dot{y}_G^2) = \frac{1}{2}m\big(l(t)\dot{\theta}(t)\big)^2+\frac{1}{2}m\big(\dot{l}(t)\big)^2 | ||
\end{equation} | ||
while the potential energy as | ||
\begin{equation} | ||
P = mgy_G = -mgl(t)\cos\theta(t) | ||
\end{equation} | ||
Using the kinetic and the potential energy, the Lagrangian equation of the VLP can be defined as | ||
\begin{equation*} | ||
L = T-P | ||
\end{equation*} | ||
Applying the Euler-Lagrangian operator on the defined Lagrangian equation $L$, where the Lagrangian operator is given as | ||
\begin{equation}\label{model} | ||
\frac{\partial L}{\partial q} -\frac{dL}{dt}\Bigg(\frac{\partial L}{\partial \dot{q}}\Bigg) = \tau | ||
\end{equation} | ||
with $q = [l, \theta]^T$ state vector and $\tau$ applied generalized forces on the VLP, it is possible to obtain the | ||
equations of motions of the system | ||
\begin{align} \label{full_model} | ||
&\Ddot{\theta}(t)+\frac{2\dot{l}(t)\dot{\theta}(t)}{l(t)} + \frac{g\sin\theta(t)}{l(t)} = 0 \\ | ||
\label{second_model} | ||
&\Ddot{l}(t)-ml(t)\dot{\theta}^2(t)-mg\cos\theta(t) = f(t) | ||
\end{align} | ||
For simplicity, the control input will be chosen to be $$u =\Ddot{l}(t)$$ | ||
where $f(t)$ can be computed directly from equation \eqref{second_model}. | ||
|
||
\section{Problem Formulation} | ||
\label{sec:problem-formulation} | ||
The total mechanical energy of the system can be expressed as the sum of the kinetic and the potential energy | ||
\begin{equation} \label{total_energy} | ||
E_T = T+P = \frac{1}{2}\dot{l}^2(t)+\frac{1}{2}\big(l(t)\dot{\theta}(t)\big)^2-gl(t)\cos\theta(t) | ||
\end{equation} | ||
where, without loss of generality, it is assumed that $m = 1$. | ||
%\paragraph{} | ||
Consider the desired trajectory of swing to be described by | ||
\begin{equation} | ||
E_r = \frac{1}{2}\big(l_r\dot{\theta}(t)\big)^2-gl_r\cos\theta(t) | ||
\end{equation} | ||
where, for a given desired length of the pendulum $l_r$ and a maximal angle $\theta_{max}$ of desired swing. $E_r$ is the | ||
desired energy, which satisfies the following | ||
\begin{eqnarray} | ||
\label{eq:Er-property} | ||
E_r = -gl_r\cos\theta_{max}, & \hfill &\theta_{max} \in (0,\pi] | ||
\end{eqnarray} | ||
The trajectory tracking problem proposed in \cite{xin2014control} is to design a control law $u$ in order to achieve the following | ||
\begin{eqnarray} \label{control_obj} | ||
\lim_{t\rightarrow \infty} E_T = E_r \ \ \ \ \ \ \lim_{t\rightarrow \infty} \dot{l} = 0 \ \ \ \ \ \ \ \ \lim_{t\rightarrow \infty} l = l_r | ||
\end{eqnarray} | ||
|
||
\end{document} |
Oops, something went wrong.