Skip to main content

Why Ethereum Smart Contracts Make It Hard to Get Payments

 

The Unique Role of Smart Contracts in Ethereum

One of Ethereum’s standout features is its ability to host diverse applications on its blockchain using smart contracts. However, these smart contracts, while powerful, sometimes complicate simple tasks. For instance, determining the amount of ETH deposited into a specific Ethereum address can be surprisingly complex. This is because you cannot understand the actions of a smart contract without executing it.

Synchronizing Blockchain Internals and Externals

Smart contracts operate exclusively within the blockchain's data, reading and writing information stored on-chain. This limitation does not prevent the creation of valuable applications, such as multi-signature wallets or tokens like ERC-20 and ERC-721, which rely solely on on-chain data. However, most practical applications also require interaction with off-chain systems.

Take cryptocurrency exchanges, for example. Exchanges facilitate converting ETH into fiat currency or vice versa. They rely on blockchain transactions to confirm payments and then interact with external systems, such as banking networks, to send or receive funds.

While such tasks could be handled entirely via smart contracts, it’s often impractical. Smart contracts are costly because every call is processed by every node in the Ethereum network—roughly 8,000 as of June 2019. Each contract execution multiplies the cost across all nodes, making certain tasks more economical to perform off-chain.

However, bridging blockchain internals with external systems is not as straightforward as it may seem.

Checking ETH Balances in Accounts

Sometimes, exchanges prohibit deposits made via smart contract wallets. Instead, they assign unique Ethereum addresses to each user and monitor deposits to those addresses. Checking an account’s ETH balance is relatively straightforward, but why might exchanges reject smart contract-based deposits?

ETH deposits typically fall into two categories: direct ETH transfers or smart contract interactions. In direct transfers, transaction details such as the sender, recipient, and value are explicitly recorded, making it easy to verify deposits. However, for transactions involving smart contracts, the situation becomes more complex. Smart contracts obscure deposit details since the transaction information doesn’t explicitly indicate the recipient or the amount. Furthermore, Ethereum's SDK lacks a built-in API for retrieving this information.

Solving the Smart Contract Deposit Challenge

To address this issue, there are three potential solutions.

  1. Direct Deposits Only
    The simplest approach is to mandate that users deposit ETH directly, avoiding smart contract wallets altogether. Early cryptocurrency exchanges adhered to this model, and many still do today, processing only direct transfers.

    Alternative Methods for Tracking ETH Deposits

    1. Checking Account Balances at Each Block
    One method is to track an account's balance at every block. By calculating the difference between the balances in the current and previous blocks, you can determine how much ETH has been deposited. However, this method has its limitations. It doesn’t provide a way to trace which transaction contributed to the balance change, making it challenging to identify the source of the deposit. Additionally, checking the balance of all managed accounts for every block is time-intensive and inefficient.

    2. Using the Trace API
    Another approach is to leverage the trace API provided by Ethereum client implementations like Go Ethereum (Geth) and Parity. These APIs allow you to analyze transactions at a granular level, tracking the exact changes made to the Ethereum Virtual Machine (EVM) state. Using this method, you can determine how much ETH a smart contract deposited into an account.

    However, there are significant drawbacks to this approach. First, it requires running a full Ethereum node, which demands substantial computational resources. Second, the APIs are not standardized across implementations and can change over time, as they are not part of Ethereum’s official specification. Additionally, using the trace API is technically complex, which can increase development effort and cost.


    Conclusion

    To summarize, there are three main methods to track ETH deposits into accounts when smart contracts are involved:

    1. Requiring direct deposits to avoid complications entirely.
    2. Monitoring account balances block by block, which is simple but lacks precision and efficiency.
    3. Utilizing trace APIs to track detailed transaction behavior, though this method is resource-intensive and technically challenging.

    Retrieving basic information about who deposited how much ETH and when remains a challenging task in Ethereum. Each method has trade-offs, so the choice of approach depends on the specific requirements and constraints of your application.


    Let me know if you'd like further adjustments or expansions!

Comments

Popular posts from this blog

Room + ViewModel + LiveData + RecyclerView (MVVM)

Part 1 - Introduction Part 2 – Entity Part 3 – DAO & RoomDatabase Part 4 – Repository Part 5 – ViewModel Part 6 – RecyclerView + Adapter Part 7 – Add Note Activity Part 8 – Swipe to Delete Part 9 – OnItemClickListener & Update Functionality Part 10 – ListAdapter                     Part 1 - Introduction In this tutorial we will build a note taking app, using the Android Architecture Component libraries (Room, ViewModel, LiveData and LifeCycle), a RecyclerView and Java. The data will be stored in an SQLite database and supports insert, read, update and delete operations. For this we will follow the official recommendations from the “Guide to App Architecture” (link below). In part 1 we will learn what the Architecture Components are, how they work and why we need them. We will learn about the problems that arise from the Activity and Fragment lifecycle, configuration changes and bloated, tightly coupled cl...

DodgeInsetEdges

The layout_dodgeInsetEdges together with the layout_insetEdge attribute, to move views within a CoordinatorLayout out of the way of other views. This behavior is the default behavior for FloatingActionButtons and Snackbars , but we will also apply it to views like normal buttons and bottom sheets. In Mainactivity.java add the code below stated:- import android.support.design.widget.BottomSheetBehavior; import android.support.design.widget.FloatingActionButton; import android.support.design.widget.Snackbar; import android.support.v7.app.AppCompatActivity; import android.os.Bundle; import android.view.View; import android.widget.Button; public class MainActivity extends AppCompatActivity {     private BottomSheetBehavior bottomSheetBehavior;     @Override     protected void onCreate(Bundle savedInstanceState) {         super.onCreate(savedInstanceState);         setContentView(R.layout.activ...