# Distributed Ledger Technology Review and Decentralized Applications Development Guidelines
## 2 Protocol and Network Tier
### Protocol Layer
#### 2.1.3 Business Rules Enforcement over Transactions  
The capability of a DLT system to support business implementation that can be run in a decentralized way, and then be verified and audited by all the nodes in the system, is usually provided through smart contracts. Opposed to the concept suggested by their names, the smart contracts are not very smart and may not provide a contract in the legal sense, but rather they are pieces of code similar to the stored procedures that are executed and validated by the nodes in the system, whenever they are triggered. However, there are DLT systems such as Bitcoin that are offering few possibilities for scripts to be implemented. Not being a Turing Complete language, the Bitcoin script language does not permit the implementation of complex business logic required for more advanced use cases. As a result, new DLT systems have emerged that allow customizing decentralized applications and enforcement of business logic in a decentralized way regarding when, how, and by whom may an asset transfer be executed.  
In Table 3 a comparison of the main state of the art approaches for enforcing the business rules on DLT is presented. There are two types of approaches that allow smart functionality to be implemented and run across the nodes of the network: stateless and stateful [55]. The Stateless implementation is offering the possibility to implement custom logic at the level of transactions. Whenever a transaction is issued there is a set of rules that can be verified before rendering the transaction valid. The Stateful systems, on the other hand, offer Business-oriented functionalities, by focusing on the rules that govern the use case, and keeping the state of the business in tamper-resistant structures (Patricia Merkle Trees, adapted from [56]) that are easily verifiable and audited by the entire distributed system. In the Stateful Systems, the transaction has the role of triggering changes and applying updates on the stored state.  
\begin{table}
\begin{tabular}{c c c c c c} \hline \hline
**Features** & \begin{tabular}{c} **Private-Public** \\ **Key Encryption** \\ \end{tabular} & \begin{tabular}{c} **Zero-Knowledge** \\ **Proofs** \\ \end{tabular} & \begin{tabular}{c} **Ring** \\ **Signatures** \\ \end{tabular} & \
\begin{tabular}{c} **Homomorphic** \\ **Encryption** \\ \end{tabular} &
\begin{tabular}{c} **Coin** \\ **Mixers** \\ \end{tabular} \\ \hline Hidden Data & yes & yes & yes & yes & no \\ Non-traceable & yes & n/a & yes & yes & yes \\ Non-linkable & no & yes & yes & no & yes \\ Decentralized & no & yes & yes & yes & no \\ Private Business Enforcement & no & yes & no & no & no \\ Transaction validation by network & no & yes & yes & yes & yes \\ \hline \hline \end{tabular}
\end{table}
Table 2: DLT main privacy presenting techniques.  
In terms of functional complexity, some systems allow full computation capabilities by supporting Turing Complete languages for smart contract implementations or partial capabilities by offering a limited range of operations or fixed predefined templates. Both approaches have their advantages. On one hand, full capabilities are desired to be able to model and enforce any complex business system. Turing Completeness allows this, but it requires higher transactional costs. The on-chain computation demands for each node to execute possibly complex scripts; thus, the costs are proportional with the number of instructions. Furthermore, a complex and flexible language makes the system susceptible to different kinds of attacks that can be caused by exploiting different language shortcomings or human errors during the business logic implementations like call depth attack, race conditions, timestamp dependency, transaction ordering dependency, etc. On the other hand, the risk of exploits is highly reduced by limiting the operations allowed or by providing predefined templates.