Key Points 

References

Key Concepts

Smart Contract Concepts - EUBOF - 2022

https://www.linkedin.com/search/results/content/?keywords=smart%20contract%20report&sid=XQ(&update=urn%3Ali%3Afs_updateV2%3A(urn%3Ali%3Aactivity%3A6996355023236403200%2CBLENDED_SEARCH_FEED%2CEMPTY%2CDEFAULT%2Cfalse)

eubof-smart-contracts-paper-2022.pdf  link

Deprecated > Creating and Deploying Smart Contracts with Solidity - Baeldung - Java interface to create, run Solidity Dapps

https://www.baeldung.com/smart-contracts-ethereum-solidity

https://github.com/eugenp/tutorials/tree/master/ethereum

A smart contract is a stand-alone script usually written in
Solidity and compiled into binary or JSON and
deployed to a specific address on the blockchain. In
the same way that we can call a specific URL endpoint of a
RESTful API to execute some logic through an HttpRequest,
we can similarly execute the deployed smart contract at a
specific address by submitting the correct data along with
the necessary Ethereum to call the deployed and compiled
Solidity function.

see a smart contract as a collection of code stored in the blockchain
network that defines conditions to which all parties using the contract agree upon.

Anyone can deploy a smart contract to the decentralized database for a fee proportional to
the storage size of the containing code. Nodes wishing to use the smart contract must
somehow indicate the result of their participation to the rest of the network.

Solidity – which is a Javascript-like language developed specifically for writing
smart contracts. Solidity is statically typed, supports
inheritance, libraries and complex user-defined types among other features.

deployment

solidity compiler turns code into EVM bytecode, which
can then be sent to the Ethereum network as a deployment
transaction. Such deployments have more substantial
transaction fees than smart contract interactions and must
be paid by the owner of the contract.

Remix IDE

We can use Remix, which's currently the best online IDE and it's effortless to use.

execute a contract from a node

run a client ourselves

OR connect to a remote node using a service like Infura.
Infura is the most straightforward option, so we'll request a free access token. Once we sign up, we need to pick the URL
of the Rinkeby test network:
“https://rinkeby.infura.io/<token>”.
To be able to transact with the smart contract from Java, we need to use a library called Web3j. Here is the Maven dependency:
<dependency>
<groupId>org.web3j</groupId>
<artifactId>core</artifactId>
<version>3.3.1</version>
</dependency>

5.1. Creating a Wallet

5.2. Requesting Ether in the Rinkeby Testnet

5.3. Generating the Smart Contract Wrapper

6. Interacting With the Smart Contract

In our main class, we start by creating a new web3j instance to connect to remote nodes on
the network:

Web3j web3j = Web3j.build(
new
HttpService("https://rinkeby.infura.io/<your_token>"));
We then need to load our Ethereum wallet file:
Credentials credentials = WalletUtils.loadCredentials(
"<password>",
"/path/to/<walletfile>");
Now let's deploy our smart contract:
Greeting contract = Greeting.deploy(
web3j, credentials,
ManagedTransaction.GAS_PRICE, Contract.GAS_LIMIT,
"Hello blockchain world!").send();
Deploying the contract may take a while depending the work in the network. Once is
deployed, we might want to store the address where the contract was deployed. We can
obtain the address this way:
String contractAddress = contract.getContractAddress();
All the transactions made with the contract can be seen in the url:
“https://rinkeby.etherscan.io/address/<contract_address>”.
On the other hand, we can modify the value of the smart contract performing a transaction:
TransactionReceipt transactionReceipt = contract.setGreeting("Hello again").send();
Finally, if we want to view the new value stored, we can simply write:
String newValue = contract.greet().send();

Ethereum Concepts

https://ethereum.org/en/developers/docs/intro-to-ethereum/

EVM Concepts

Gimer Cervera

https://www.linkedin.com/posts/gimercervera_ethereum-virtual-machine-evm-deep-dive-activity-7147970421055782914-2kQu?utm_source=share&utm_medium=member_desktop

Last week I posted an article on Medium related to the Ethereum Virtual Machine (EVM) and some insights related to inline assembly. The goal of the material is to explore in detail the EVM and learn how to code more efficient and secure smart contracts. In this post, I'd like to share other inspirational resources so you can improve your knowledge on this exciting field.

EVM Medium article: https://lnkd.in/eiXn-pp2

✅ Andreas Antonopoulos - The Ethereum Virtual Machine: https://lnkd.in/eB2JXDwz

✅ Femboy Capital - A Playdate with the EVM: https://lnkd.in/ezdADJAZ

✅ Solidity Tutorial All About Assembly: https://lnkd.in/eBU75N6x

✅ Openzeppelin - Deconstructing a Solidity Contract: https://lnkd.in/evqRvgs4

✅ Diving Into the Ethereum Virtual Machine: https://lnkd.in/eG6F2YEg

If you want to review more resources, you can find a curated list of articles and videos in my github account: https://lnkd.in/eK_XB-UU

Enjoy!

EVM Deep Dive - Part 1 - artlcle

evm-concepts-p1-2023-medium.com-Ethereum Virtual Machine EVM Deep Dive Part I .pdf.  link

evm-concepts-p1-2023-medium.com-Ethereum Virtual Machine EVM Deep Dive Part I .pdf. file

Ether Concepts

https://ethereum.org/en/developers/docs/intro-to-ether/

Ethereum Accounts

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

Ethereum has two account types:

• Externally-owned account (EOA) – controlled by anyone with the private keys
• Contract account – a smart contract deployed to the network, controlled by code. Learn about smart contracts

Both account types have the ability to:

• Receive, hold and send ETH and tokens
• Interact with deployed smart contracts

Key differences on EOA vs CA

Externally-owned

• Creating an account costs nothing
• Can initiate transactions
• Transactions between externally-owned accounts can only be ETH/token transfers
• Made up of a cryptographic pair of keys: public and private keys that control account activities

Contract

• Creating a contract has a cost because you're using network storage
• Can only send transactions in response to receiving a transaction
• Transactions from an external account to a contract account can trigger code which can execute many different actions, such as transferring tokens or even creating a new contract
• Contract accounts don't have private keys. Instead, they are controlled by the logic of the smart contract code

Account Abstraction overview

https://blog.pantherprotocol.io/ethereum-account-abstraction-everything-you-need-to-know/

Externally Owned Accounts (EOA)

A 'regular' Ethereum account with which you can initiate transactions, send, and receive ETH or any other Ethereum-based token (ERC-20, ERC-721, etc), and interact with smart contracts is an externally owned account (EOA). The average Ethereum user owns an EOA, and through wallets, the account interacts with the blockchain.

Externally owned Ethereum accounts cost nothing to create, as they incur no storage requirements. They are simple accounts unassociated with data storage or code. EOAs are the only Ethereum account type with private keys, and these private keys have control over transaction signing. Also, when two EOAs interact, they can only initiate ETH or token transfers.

In summary, an externally owned Ethereum account has a public address and a private key, can initiate transactions and interact with smart contracts, requires no storage, and is represented on the EVM with an empty code string.

Contract Accounts (CA)

Contract accounts are a tad different from EOAs, as a code written on the EVM controls their activities. They are also commonly known as smart contracts. This code, once written, cannot be altered and will define the nature of transactions the contract account can complete. CAs do not initiate transactions, unlike their EOA counterparts. Instead, they can only send transactions in response to a transaction received.

For example, if you send a token to a contract account to exchange said for ETH tokens, the CA receives your transaction and, through its code, sends the corresponding amount of ETH to your address. Apart from being able to transfer tokens, contract accounts can also create new contracts.

Since CAs are controlled by their code's logic, they do not have private keys. Also, contract accounts use network storage. As such, creating them comes at a cost. The nonce of a contract account counts the number of contracts every specific CA has created.

What is Ethereum account abstraction?

Data abstraction in computer science translates to hiding information to increase efficiency. For example, a software developer can learn how to write a compiler or understand the mechanisms between the compiler, processors, or memory functions when building with high-level programming languages. Data abstraction keeps the 0s and 1s underneath, allowing developers to work directly with more friendly languages, saving time and allowing for more complex operations.

In the case of Ethereum, account abstraction seeks to eliminate the existence of two types of accounts by unifying them. Thus, a single contract account will be empowered to transact with tokens and create contracts, unifying both account types. Instead of being separate account types, both EOAs and CAs will fall under a single type.

With this change, transactions will move off the blockchain and onto the EVM, eliminating the distinction between accounts. Let’s look into what exactly motivates this idea, whether it is truly achievable, and what are its benefits.

AN ACCOUNT EXAMINED

Ethereum accounts have four fields:

• nonce – A counter that indicates the number of transactions sent from the account. This ensures transactions are only processed once. In a contract account, this number represents the number of contracts created by the account.
• balance – The number of wei owned by this address. Wei is a denomination of ETH and there are 1e+18 wei per ETH.
• codeHash – This hash refers to the code of an account on the Ethereum virtual machine (EVM). Contract accounts have code fragments programmed in that can perform different operations. This EVM code gets executed if the account gets a message call. It cannot be changed, unlike the other account fields. All such code fragments are contained in the state database under their corresponding hashes for later retrieval. This hash value is known as a codeHash. For externally owned accounts, the codeHash field is the hash of an empty string.
• storageRoot – Sometimes known as a storage hash. A 256-bit hash of the root node of a Merkle Patricia trie that encodes the storage contents of the account (a mapping between 256-bit integer values), encoded into the trie as a mapping from the Keccak 256-bit hash of the 256-bit integer keys to the RLP-encoded 256-bit integer values. This trie encodes the hash of the storage contents of this account, and is empty by default.

Diagram adapted from Ethereum EVM illustrated

EXTERNALLY-OWNED ACCOUNTS AND KEY PAIRS

An account is made up of a cryptographic pair of keys: public and private. They help prove that a transaction was actually signed by the sender and prevent forgeries. Your private key is what you use to sign transactions, so it grants you custody over the funds associated with your account. You never really hold cryptocurrency, you hold private keys – the funds are always on Ethereum's ledger.

This prevents malicious actors from broadcasting fake transactions because you can always verify the sender of a transaction.

If Alice wants to send ether from her own account to Bob’s account, Alice needs to create a transaction request and send it out to the network for verification. Ethereum’s usage of public-key cryptography ensures that Alice can prove that she originally initiated the transaction request. Without cryptographic mechanisms, a malicious adversary Eve could simply publicly broadcast a request that looks something like “send 5 ETH from Alice’s account to Eve’s account,” and no one would be able to verify that it didn’t come from Alice.

ACCOUNT CREATION

When you want to create an account most libraries will generate you a random private key.

A private key is made up of 64 hex characters and can be encrypted with a password.

Example:

fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd036415f

The public key is generated from the private key using the Elliptic Curve Digital Signature Algorithm. You get a public address for your account by taking the last 20 bytes of the Keccak-256 hash of the public key and adding 0x to the beginning.

The following example shows how to use a signing tool called Clef to generate a new account. Clef is an account management and signing tool that comes bundled with the Ethereum client, Geth. The clef newaccount command creates a new key pair and saves them in an encrypted keystore.

Geth documentation

It is possible to derive new public keys from your private key but you cannot derive a private key from public keys. This means it's vital to keep a private key safe and, as the name suggests, PRIVATE.

You need a private key to sign messages and transactions which output a signature. Others can then take the signature to derive your public key, proving the author of the message. In your application, you can use a javascript library to send transactions to the network.

CONTRACT ACCOUNTS

Contract accounts also have a 42 character hexadecimal address:

Example:

0x06012c8cf97bead5deae237070f9587f8e7a266d

The contract address is usually given when a contract is deployed to the Ethereum Blockchain. The address comes from the creator's address and the number of transactions sent from that address (the “nonce”).

VALIDATOR KEYS

There is also another type of key in Ethereum, introduced when Ethereum switched from proof-of-work to proof-of-stake based consensus. These are 'BLS' keys and they are used to identify validators. These keys can be efficiently aggregated to reduce the bandwidth required for the network to come to consensus. Without this key aggregation the minimum stake for a validator would be much higher.

More on validator keys.

A NOTE ON WALLETS

An account is not a wallet. An account is the keypair for a user-owned Ethereum account. A wallet is an interface or application that lets you interact with your Ethereum account.

A VISUAL DEMO

Watch Austin walk you through hash functions, and key pairs.

Ethereum Account Abstraction proposal ( EIP-2938 )

https://eips.ethereum.org/EIPS/eip-2938

Account abstraction (AA) allows a contract to be the top-level account that pays fees and starts transaction execution.

Transaction validity, as of Muir Glacier, is defined rigidly by the protocol: ECDSA signature, a simple nonce, and account balance. Account abstraction extends the validity conditions of transactions with the execution of arbitrary EVM bytecode (with some limits on what state may be accessed.) To signal validity, we propose a new EVM opcode PAYGAS, which also sets the gas price and gas limit the contract is willing to pay.

We split account abstraction into two tiers: single-tenant AA, which is intended to support wallets or other use cases with few participants, and multi-tenant AA, which is intended to support applications with many participants (eg. tornado.cash, Uniswap).

The existing limitations preclude innovation in a number of important areas, particularly:

1. Smart contract wallets that use signature verification other than ECDSA (eg. Schnorr, BLS, post-quantum…)
2. Smart contract wallets that include features such as multisig verification or social recovery, reducing the highly prevalent risk of funds being lost or stolen
3. Privacy-preserving systems like tornado.cash
4. Attempts to improve gas efficiency of DeFi protocols by preventing transactions that don’t satisfy high-level conditions (eg. existence of a matching order) from being included on chain
5. Users being able to pay for transaction fees in a token other than ETH (eg. by converting that token into the ETH needed for fees inside the transaction in real-time)

Most of the above use cases are currently possible using intermediaries, most notably the Gas Station Network and application-specific alternatives. These implementations are (i) technically inefficient, due to the extra 21000 gas to pay for the relayer, (ii) economically inefficient, as relayers need to make a profit on top of the gas fees that they pay.

In an account abstraction setup, the goal is to allow accounts to specify EVM code that can establish more flexible conditions for a transaction’s validity, but with the requirement that this EVM code can be quickly verified, with the same safety properties as the existing setup.

Ethereum Transactions

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

Transactions are cryptographically signed instructions from accounts. An account will initiate a transaction to update the state of the Ethereum network. The simplest transaction is transferring ETH from one account to another.

Transactions, which change the state of the EVM, need to be broadcast to the whole network. Any node can broadcast a request for a transaction to be executed on the EVM; after this happens, a validator will execute the transaction and propagate the resulting state change to the rest of the network.

Transactions require a fee and must be included in a validated block. 

But a transaction object needs to be signed using the sender's private key. This proves that the transaction could only have come from the sender and was not sent fraudulently.

An Ethereum client like Geth will handle this signing process.

{
  "id": 2,
  "jsonrpc": "2.0",
  "method": "account_signTransaction",
  "params": [
    {
      "from": "0x1923f626bb8dc025849e00f99c25fe2b2f7fb0db",
      "gas": "0x55555",
      "maxFeePerGas": "0x1234",
      "maxPriorityFeePerGas": "0x1234",
      "input": "0xabcd",
      "nonce": "0x0",
      "to": "0x07a565b7ed7d7a678680a4c162885bedbb695fe0",
      "value": "0x1234"
    }
  ]
}

<<< RESPONSE
{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "raw": "0xf88380018203339407a565b7ed7d7a678680a4c162885bedbb695fe080a44401a6e4000000000000000000000000000000000000000000000000000000000000001226a0223a7c9bcf5531c99be5ea7082183816eb20cfe0bbc322e97cc5c7f71ab8b20ea02aadee6b34b45bb15bc42d9c09de4a6754e7000908da72d48cc7704971491663",
    "tx": {
      "nonce": "0x0",
      "maxFeePerGas": "0x1234",
      "maxPriorityFeePerGas": "0x1234",
      "gas": "0x55555",
      "to": "0x07a565b7ed7d7a678680a4c162885bedbb695fe0",
      "value": "0x1234",
      "input": "0xabcd",
      "v": "0x26",
      "r": "0x223a7c9bcf5531c99be5ea7082183816eb20cfe0bbc322e97cc5c7f71ab8b20e",
      "s": "0x2aadee6b34b45bb15bc42d9c09de4a6754e7000908da72d48cc7704971491663",
      "hash": "0xeba2df809e7a612a0a0d444ccfa5c839624bdc00dd29e3340d46df3870f8a30e"
    }
  }
}

DApps Concepts

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

Ethereum Smart Contract Development Languages

https://ethereum.org/en/developers/docs/smart-contracts/languages/

Ethereum and Web3 apps

https://ethereum.org/en/developers/docs/web2-vs-web3/

Your App: What goes on the blockchain?  Why?

What are the costs?

What is the trust model for the app and parties?

Why is the blockchain needed for trusts?

Ethereum Layer 2 roadmap

https://cointelegraph.com/news/vitalik-buterin-outlines-endgame-roadmap-for-eth-2-0

layer2-Vitalik Buterin outlines endgame roadmap for ETH 20.pdf

both optimistic and zero knowledge proof rollups

https://finance.yahoo.com/news/ethereum-no-longer-one-chain-123000149.html

Ethereum is no longer a one-chain ecosystem. In order to achieve scalability, the Ethereum community will need to offer layer 2 technologies capable of handling transactions from billions of users. 2021 proved to be the first step in experimentation with both optimistic and zero knowledge proof rollups, and the two finally began to take significant market share in daily transactions away from Ethereum L1.

Ethereum Smart Contract Development

https://medium.com/blockchain-stories/the-story-of-an-ethereum-smart-contract-e0df5c526724

ethereum-smart-contract-dev-p1-The Story Of An Ethereum Smart Contract _ by Kerala Blockchain Academy _ Blockchain Stories _ Jun, 2022 _ Medium.pdf file

ethereum-smart-contract-dev-medium.com-Interacting with an Ethereum Smart Contract.pdf file

Basic steps to run a smart contract on a blockchain

1. The distributed ledger should be equipped to record computer programs.
2. Whenever a user executes a DApp, the execution should happen at every peer/computer holding the ledger copy.
3. The nodes (network participants holding the blockchain copy) should have an execution environment to execute the DApp.
4. The system should have a mechanism to uniquely identify a program, its associated data and its executions.
5. Finally, these changes should be recorded as transactions on the chain.

Smart contract environment

• Smart contracts ( SC ) run on an emulated computer called the Ethereum Virtual Machine (EVM).
• Each node on the Ethereum network runs a local copy of the EVM to validate contract execution.
• At the same time, the Ethereum blockchain records the changing state of this world computer as it processes transactions and smart contracts. 
• The EVM operates like a global, single-instance computer, running everywhere.
• Each smart contract is uniquely identified by its 20-byte contract address and has a smart contract program code
• Each SC is owned and controlled by the logic of its smart contract program code that is recorded on the Ethereum blockchain at the contract account’s creation and executed by the EVM.
  • No one can steal the funds of a smart contract since it does not have a private key to be stolen.
• Contract funds are accessed only by programming the transfers in the smart contract code, which is publicly auditable.
• Externally Owned Accounts or EOAs are controlled by users using their private keys.
  • They are often managed by wallet applications external to the Ethereum platform.
• Smart contract deployment is also a blockchain transaction
• Smart contracts are written in high-level languages like Solidity

// SPDX-License-Identifier: MIT
pragma solidity 0.8.7;

contract MyContract {
    string message = "Hello Ethereum";

    function setMessage(string memory _message) public {
        message = _message;
    }

    function getMessage() public view returns (string memory) {
        return message;
    }
}

Smart Contract Gas Fees on Ethereum

Ethereum introduces a metering mechanism called gas. As the EVM executes a smart contract, it carefully accounts for every instruction (computation, data access, etc.). Each instruction has a predetermined cost in units of gas. When a transaction triggers the execution of a smart contract, it must include an amount of gas that sets the upper limit of what can be consumed running the smart contract. The EVM will terminate execution if the amount of gas consumed by computation exceeds the gas available in the transaction.

 The Solidity compiler (solc) converts the smart contract to EVM bytecode

The compiler also generates an Application Binary Interface (ABI). ABI serves as an interface between two program modules. It defines how data structures and functions are accessed in machine code.

Deployment after compile

the contract can be deployed using a particular contract deployment transaction. Once the transaction is included in a block, the contract can be referred to by its address. The address of a smart contract is calculated as a hash function of the originating account and account nonce (number of transactions originated from an account).

An Ethereum user who wants to interact with a smart contract can use the contract address and ABI to interact with it anytime.

MyContract is deployed in Ropsten testnet at contract address 0x0dFA0638dd508bFb4E13A06359FAF666677D7F4d. You can check the contract status at the block explorer.

Interact with Ethereum Smart Contracts

https://medium.com/blockchain-stories/interacting-with-an-ethereum-smart-contract-aa14401c30a0

ethereum-smart-contract-dev-medium.com-Interacting with an Ethereum Smart Contract.pdf

Please note that in the previous article we deployed the smart contract in Ropsten test network. Since Ropsten test network is expected to be shut down later this year, we have used a similar smart contract deployed in Goerli testnet here.

Contract Address (Goerli): 0x44E84A10341BF772906c37fFc30CDbb132eA35f2

https://goerli.etherscan.io/address/0x44e84a10341bf772906c37ffc30cdbb132ea35f2

Connect your test wallet to the testnet

We can interact with an already deployed smart contract by using its contract address and the ABI. For that, we first need to connect to the blockchain network. Wallets are simple applications allowing users to connect with a blockchain network. They act as account managers who manage the user’s keys and transactions. We will be using a MetaMask wallet to connect with the Goerli test network, which got our smart contract. MetaMask installation is already described in our previous blog on HD Wallets. Kindly follow those instructions to install MetaMask.

Connection goes to mainnet so switch to the testnet

Get test ether from a faucet to fund your wallet

Click on the network name, and enable visibility of test networks. Now switch to Goerli test network.

To interact with the contract using the wallet, it should have some ether balance. Goerli is a test network, and its cryptocurrency (Goerli ETH) is available for free from certain sources called faucets. You can go to any of the below links and request Goerli ETH by sharing your account address.

Faucets: https://goerli-faucet.slock.it/, https://faucet.goerli.mudit.blog/. Remember, these are test ethers which do not have any monetary value.

Interact with the Contract thru an IDE

Remix IDE is an open-source web and desktop application. You can directly access it from your web browser; just go to https://remix.ethereum.org.

Open a new file and copy the ABI from https://goerli.etherscan.io/address/0x44E84A10341BF772906c37fFc30CDbb132eA35f2#code. Save it as filename.abi

Switch to the deploy and run transaction tab from the menu on the left side. Select the environment as Injected Web3 to connect with the MetaMask. Make sure you are logged into MetaMask and connected to the Goerli testnet. Enter the contract address (0x44E84A10341BF772906c37fFc30CDbb132eA35f2) at the designated place and click on At Address as shown in the figure. Remix IDE will ask you for confirmation before loading the contract instance. An instance of the contract will be available under the heading deployed contracts. You can expand it to interact with it.

CALL vs TRANSACTION

Try to invoke the getMessage function by clicking on it. At the console below the editor space, you will get the status of the method call.

The getMessage function of our contract performs a simple read-only operation (CALL), which returns the current value of the message stored on the blockchain. You will be able to view the present value of the message in the log and below the function under deployed contracts.

Now, try to invoke the setMessage function. This function writes a value to the message and stores it on the blockchain. Give a string in the textbox and click on the setMessage.

Since it performs a write operation on the blockchain state, the method invocation is a transaction. The MetaMask will pop up and ask you for transaction confirmation. This operation carries a fee, as displayed in the wallet notification, and it will be deducted from your account. The cost depends upon the requested operation and also some dynamic network parameters. The same function may require a different fee at a later time.

Click on confirm. MetaMask will use your private key to sign the transaction and send it across the network. Once it gets verified by the network and added to the block, you will get a confirmation from MetaMask (it may take approximately 10–15 seconds). The transaction details can be seen in the Remix IDE console also.

Click on the view on etherscan option to view transaction in etherscan. The transaction input data will be in a default encoded format. Click on decode input data to view it in text format.

Deploy a copy of this contract

Do you wish to deploy the smart contract independently?. It’s simple, just copy the contract source code of the smart contract and save it in a .sol file in Remix IDE. Now go to the solidity compiler tab and compile the smart contract. Make sure you see a tick on the compilation icon.

Next, go to the deploy and run transactions tab. Make sure that your MetaMask is active and connected to the test network.

Select deployment environment as Injected Web3 to connect to MetaMask. Deploy the contract. Confirm the MetaMask transaction notification and wait until your contract deployment transaction is confirmed. Now you can interact with the newly deployed smart contract.

Create Solidity Smart Contracts - Baeldung

https://www.baeldung.com/smart-contracts-ethereum-solidity

Creating and Deploying Smart Contracts with Solidity-baeldung.com.pdf link

EVM overview of contract types

From a practical standpoint, the EVM can be thought of as a large, decentralized system containing millions of objects, called accounts, which can maintain an internal database, execute code and talk to each other.

The first type of account is probably the most familiar for the average user who uses the network. Its name is EOA (Externally Owned Account); it is used to transmit value (such as Ether) and is controlled by a private key.

On the other hand, there is another type of account which is the contract. Let's go ahead and see what is this about:

Web3j - run a Java class via API on an Ethereum client

https://docs.web3j.io/4.8.7/

Java and the Blockchain by Conor Svensson

https://www.youtube.com/watch?v=ea3miXs_P6Y

Web3j is a highly modular, reactive, type safe Java and Android library for working with Smart Contracts and integrating with clients (nodes) on the Ethereum network:

Web3j is a lightweight, highly modular, reactive, type safe Java and Android library for working with Smart Contracts and integrating with Ethereum blockchains.

This allows you to work with Ethereum blockchains, without the additional overhead of having to write your own integration code for the platform.

• Web3j integrates seamlessly with the Epirus Blockchain Explorer
• Web3j is 100% open source and maintained by Web3 Labs
• Create projects to work with new or import existing decentralised apps in a single command with the Web3j CLI
• Plugins for leading build tools to simplify the developer experience
• Simple to use framework for automated integration testing against networks 
 within your IDE

Features

• Complete implementation of Ethereum's JSON-RPC client API over HTTP and IPC
• Ethereum wallet support
• Auto-generation of Java smart contract wrappers to create, deploy, transact with and call smart contracts from native Java code (Solidity and Truffle definition formats supported)
• Reactive-functional API for working with filters
• Ethereum Name Service (ENS) support
• Support for OpenEthereum's Personal, and Geth's Personal client APIs
• Support for Alchemy and Infura, so you don't have to run an Ethereum client yourself
• Support for ERC20 and ERC721 token standards
• Comprehensive integration tests demonstrating a number of the above scenarios
• Command line tools
• Android compatible
• Support for JP Morgan's Quorum via web3j-quorum

runtime dependencies:

• RxJava for its reactive-functional API
• OKHttp for HTTP connections
• Jackson Core for fast JSON serialisation/deserialization
• Bouncy Castle for crypto
• Jnr-unixsocket for *nix IPC (not available on Android)

It also uses JavaPoet for generating smart contract wrappers

Convert Solidity Contract to a Java Class for Web3j

https://linuxtut.com/en/7ab984027aa8ff14e4b7/

If you want to use the contract used in solidity with web3j, you need to use Java classes to operate the contract.

Ethereum Optimizations

Optimistic Roll up strategies to combine offline transactions online

https://www.coindesk.com/layer2/2022/02/16/ethereums-rollups-arent-all-built-the-same/

Optimistic rollups do not largely change the trust assumptions of Ethereum, as any user is capable of running a sequencer (Arbitrum full node) that processes transactions and allows users to withdraw funds to mainnet. Sequencers are required to put up a “fidelity bond” on mainnet, thereby creating a financial incentive to be truthful. If another user disputes the sequencer’s transactions, and they are found to be dishonest, the fidelity bond is paid out to the disputer. Financial incentives and multiple sequencers will allow the layer 2s to have strong uptime performance and lean on Ethereum’s security without the concern of interference.

By socializing gas cost across bundled users and only posting calldata to mainnet, Optimistic rollups are able to achieve transaction fees 10-100x cheaper than the corresponding transaction on Ethereum layer 1. These fees will continue to get cheaper as data storage is optimized on mainnet for rollups and sharding, splitting the network in multiple chains to relieve congestion, is eventually implemented.

ZK Rollups

Zero knowledge (zk) rollups bunch together hundreds of off-chain transactions using extensive computation and post them bundled to mainnet in what is known as a “validity proof.” The validity proof is the already computed state of the layer 2 that is sent to mainnet for storage, which contains much less data than the calldata used in Optimistic rollups. Starkware, Polygon Hermez and zkSync are a few of the first implementations of Ethereum based zk rollups creating low cost, application specific layer 2s

Since zk rollups are so computationally intensive and is of limited to a few use cases.

EIP for Stake withdrawals

A new Ethereum Improvement Proposal (EIP) would set the foundation for staked ether withdrawals after the transition to proof-of-stake. BACKGROUND: While the EIP won’t immediately allow validator withdrawals, it sets the stage for the simple upgrade that makes the process possible.

POS consensus

Web3 frameworks for Ethereum

https://web3js.readthedocs.io/en/v1.2.0/getting-started.html

The web3.js library is a collection of modules which contain specific functionality for the ethereum ecosystem.

• The web3-eth is for the ethereum blockchain and smart contracts
• The web3-shh is for the whisper protocol to communicate p2p and broadcast
• The web3-bzz is for the swarm protocol, the decentralized file storage
• The web3-utils contains useful helper functions for Dapp developers.

// in node.js use: var Web3 = require('web3');

var web3 = new Web3(Web3.givenProvider || "ws://localhost:8546");

EEA Off-Chain Trusted Computing Spec

https://entethalliance.github.io/trusted-computing/spec.html

This document specifies APIs that enable off-chain Trusted Computing for Enterprise Ethereum. In this release, The Trusted Computing specification enables privacy in blockchain translations, moving intensive processing from a main blockchain to improve scalability and latency, and support of attested Oracles

This specification has four objectives:

• Support private transactions on a blockchain between mutually-untrusting parties without disclosing transaction details to other parties who also have access to the blockchain.
• Support disclosure of selected information to chosen parties on a blockchain, while maintaining the secrecy of other information from those same chosen parties ("selective Privacy").
• Move intensive processing from a main blockchain to an off-chain Trusted Compute capability thereby improving throughput and scalability.
• Support Attested Oracles.

These objectives are achieved by executing some parts of a blockchain transaction off the main chain in off-chain trusted computing. There are currently three types of Trusted Compute that are supported by this specification:

• Trusted Execution Environments (Hardware based)
• Zero-Knowledge Proofs (Software based)
• Trusted Multi-Party-Compute (MPC) (Software/Hardware based)

The APIs are grouped in registration, invocation and receipt handing sections. Attested Oracles are considered a special application of Trusted Compute used to create increased trust in an Oracle, and can be implemented using the defined APIs.

Article on EEA TCE

https://blog.chain.link/driving-demand-for-enterprise-smart-contracts-using-the-trusted-computation-framework-and-attested-oracles-via-chainlink/

Blockchains can greatly enhance their capacity to meet enterprise requirements around privacy and scalability by using Chainlink oracles to route transactional computation off-chain to the Trusted Computation Framework (TCF).

advantages and limitations of public blockchains, as well as outline the TCF architecture and how attested oracles via Chainlink can enable bi-directional connectivity between on-chain and off-chain environments. To demonstrate how this system works, we detail three industry uses cases in finance, insurance, and global trade in which TCF, Chainlink, and underlying blockchains can work in unison to improve backend business processes and reduce costs for both enterprises and consumers.

Key Points on Ethereum Public Blockchains

1. the infrastructure that powers multi-party transactional contracts. They offer a shared computational platform that stores, maintains, executes, and settles the contract for all parties involved. Participating parties can neither decommit from their obligations nor tamper with the process once the contract is set in motion on the blockchain
2. No need to trust counterparty or trusted 3rd party
3. Data-driven Contract deliverables can automatically be confirmed in many cases ( eg payment, shipments, receipts etc )
4. Lower cost, friction, time to settle with smart contracts
5. Better transparency and traceability ( provenance ) on origins ( eg Food Trust network tracks lots )
6. KYC compliance possible with Self-Sovreign Identities and Zero-Trust Knowledge proofs on public chains where supported

Challenges to overcome on public blockchains

1. Scalability ( to fit specific use cases )
2. Privacy
3. On-chain data scope

Off-chain data, privacy and execution needed to meet these challenges.

Integration with smart contracts needed via trusted agents or oracles.

Trusted agents option

1. Trusted agent is invoked by client apps or services
2. Agent executes in trusted environment and can access both off-chain data and services as well as on-chain contracts and data
3. Agent executes at top level, invokes contract as a service passing required data to the contract including

Oracles option

Blockchain App Development Concepts 101 - slideshare - sweetbridge

https://www.slideshare.net/Synerzip/blockchain-application-development-101

blockchain-application-development-webinar-sweetbridge-190905082233.pdf

Alternate Chains - some EVM compatible

Polygon - faster, low cost EVM compatible protocol delivers a POS multi-chain system

https://coinmarketcap.com/currencies/polygon/

Polygon effectively transforms Ethereum into a full-fledged multi-chain system (aka Internet of Blockchains). This multi-chain system is akin to other ones such as Polkadot, Cosmos, Avalanche etc. with the advantages of Ethereum’s security, vibrant ecosystem and openness.

The $MATIC token will continue to exist and will play an increasingly important role, securing the system and enabling governance.

Polygon (formerly Matic Network) is a Layer 2 scaling solution backed by Binance and Coinbase. The project seeks to stimulate mass adoption of cryptocurrencies by resolving the problems of scalability on many blockchains.

Polygon combines the Plasma Framework and the proof-of-stake blockchain architecture. The Plasma framework used by Polygon as proposed by the co-founder of Ethereum, Vitalik Buterin, allows for the easy execution of scalable and autonomous smart contracts.

Nothing will change for the existing ecosystem built on the Plasma-POS chain. With Polygon, new features are being built around the existing proven technology to expand the ability to cater to diverse needs from the developer ecosystem. Polygon will continue to develop the core technology so that it can scale to a larger ecosystem.

Polygon boasts of up to 65,000 transactions per second on a single side chain, along with a respectable block confirmation time of less than two seconds. The framework also allows for the creation of globally available decentralized financial applications on a single foundational blockchain.

The Plasma framework gives Polygon the potential of housing an unlimited number of decentralized applications on their infrastructure without experiencing the normal drawbacks common on proof-of-work blockchains. So far, Polygon has attracted more than 50 DApps to its PoS-secured Ethereum sidechain.

MATIC, the native tokens of Polygon, is an ERC-20 token running on the Ethereum blockchain. The tokens are used for payment services on Polygon and as a settlement currency between users who operate within the Polygon ecosystem. The transaction fees on Polygon sidechains are also paid in MATIC tokens.

Polygon provides a good approach to the Blockchain trilemma

https://coinmarketcap.com/alexandria/glossary/blockchain-trilemma

decentralization, security and scalability — that developers encounter when building blockchains, forcing them to ultimately sacrifice one "aspect" for as a trade-off to accommodate the other two. 

Polygon performance - 65,000 TPS,  2 second block finalization, $.01 transaction fee -  221016

https://www.investopedia.com/polygon-matic-definition-5217569#:~:text=Ability%20to%20process%20transactions%20quickly,8

• Ability to process transactions quickly: By using a consensus mechanism that completes the transaction confirmation process in a single block, Polygon can maintain fast transaction processing speeds. Polygon's average block processing time is 2.1 seconds.8

Polygon uses sidechains

https://coinmarketcap.com/alexandria/glossary/side-chain

Polygon uses Layer 2 for scalability

https://coinmarketcap.com/alexandria/glossary/layer-2

Layer 2 is the name given to a scaling solution that enables high throughput of transactions while fully inheriting the security of the underlying blockchain that it is built on. 

Zero Knowledge Rollups

Ethereum Scaling Tool Polygon Launches its zkEVM Public Testnet

https://finance.yahoo.com/news/ethereum-scaling-tool-polygon-launches-160000399.html

Polygon is a scaling tool aiming to facilitate lower-cost transactions, and uses the Ethereum blockchain as its base protocol. With the introduction of zero-knowledge (ZK) rollup technology, Polygon is hoping to become the chief scalable system for Ethereum.

With the public testnet going live, some of the biggest decentralized finance (DeFi) platforms, including Aave and Uniswap, as well as Web3 social platform Lens, will be among the first protocols to make use of the zkEVM testnet.

https://coinmarketcap.com/alexandria/glossary/zero-knowledge-rollups

ZK Rollups allow blockchains to validate transactions faster while also ensuring that gas fees remain minimal. Zk-rollups manage to perform better than traditional Layer 1 blockchains like Ethereum because they combine on and off-chain processes. 

zk-rollup consists of two Merkle Trees which are both stored on a smart contract, or in other words, on-chain. One tree is dedicated to storing accounts, while the other stores all balances. Any other type of data generated and used by the zk-rollup is stored off-chain.

as less of the blockchain’s capacity is utilized for transaction validation, gas fees decrease

Optimistic Rollups don't require Trusts up front for faster processing but can orphan bad blocks

https://coinmarketcap.com/alexandria/article/optimistic-rollups-for-the-rest-of-us

ORUs support smart contracts with open participation, like Uniswap.

ORUs do not require that users lock up capital upfront.

Unlike channels and Plasma, ORUs are resistant to chain congestion, since fraud is proven at the block level rather than the channel closure or Plasma exit level.

ORU blocks can be posted to Ethereum immediately. Since valid ORU blocks can't be rolled back, they have the same finality guarantees as Ethereum as soon as they're posted to Ethereum.

community has embraced ORUs wholeheartedly as a way to scale Ethereum-style smart contract execution without having to wait for Serenity Phase 2.

https://polygon.technology/

Polygon believes in Web3 for all. Polygon is a decentralised Ethereum scaling platform that enables developers to build scalable user-friendly dApps with low transaction fees without ever sacrificing on security.

Polygon combines the best of Ethereum and sovereign blockchains into a full-fledged multi-chain system.

It is able to fully benefit from Ethereum’s network effects
It is inherently more secure
It is more open and powerful

Questions

1. access controls and models
2. security
3. governance and insurance
4. protocol support
5. interoperability
6. dev tooling
7. firefly fit, portability

Stripe uses polygon for crypto payments network

https://stripe.com/blog/expanding-global-payouts-with-crypto

While the “store of value” aspects of cryptocurrencies typically receive the most attention, we view the prospect of “open-access global financial rails” as being at least equally compelling. As a result, we’ve been exploring ways to use cryptocurrency-based platforms to unlock broader access.

Today, we’re introducing crypto payouts for Connect. With crypto payouts, a select group of creators on Twitter—our first partner—will be able to use cryptocurrency-based rails to receive their earnings from Twitter.

With crypto payouts for Connect, Twitter will make it possible for creators who opt in to have their earnings paid out to a cryptocurrency wallet. Stripe will handle all crypto-related complexity and operations. No code changes are required, and platforms can avoid taking on the challenges of acquiring, storing, or transferring crypto themselves.

Stripe will initially support payouts in USDC, a stablecoin pegged to the US dollar. This will enable many people who wouldn’t otherwise be able to hold dollars to do so. Payouts will take place over the Polygon network, which we chose for its low fees, speed, integration with Ethereum, and broad wallet compatibility (including MetaMask, Coinbase Wallet, and Rainbow). Once creators receive their earnings, they can hold their balance on Polygon, or choose to bridge to Ethereum and exchange it into another currency. We plan to add support for additional rails and payout currencies over time.

wikipedia on polygon

https://en.wikipedia.org/wiki/Polygon

Polygon (formerly MATIC Network) is an Indian blockchain scalability platform. It addresses the challenges faced by Ethereum such as high fees, poor user experience, and low transaction count per second. One of the methods used to address these issues is providing a framework for Proof of Stake transactions.^[3] It aims to create a multi-chain blockchain ecosystem compatible with Ethereum.^[4] Polygon uses MATIC as its native token.

In April 2022, financial solutions company Stripe chose Polygon for cryptocurrency payments for its “low fees, speed, integration with Ethereum, and compatibility with many wallets”. Twitter was the first beneficiary of the service powered by Polygon

https://www.fool.com/investing/2022/09/15/polygons-latest-announcement-signals-a-rare-buying/?source=eptyholnk0000202&utm_source=yahoo-host&utm_medium=feed&utm_campaign=article

they believe that Ethereum will be the primary blockchain of Web3. But in order for Ethereum to reach the masses cost effectively and Web3 to become mainstream, Polygon will need to be utilized. Co-founder of polygon, Mihailo Bjelic, envisions Polygon eventually becoming "the holy grail of Web3 infrastructure." He believes the ideal Web3 blockchain should possess three primary characteristics: "scalability, security, and Ethereum compatibility" -- something Polygon surely possesses.

Compare Polygon, Solana and Ethereum on performance, cost

https://www.blockchain-council.org/blockchain/solana-vs-polygon-vs-ethereum/

Polygon and Solana have different approaches to performance

https://finance.yahoo.com/news/solana-vs-polygon-developer-perspective-151000538.html

Solana vs Polygon A Developers Perspective.pdf file

Solana vs Polygon A Developers Perspective.pdf  link

On Solana, blocks can theoretically reach a maximum size of 128MB. The Solana Turbine protocol breaks a block into 1280 byte packets called shreds. Through Solana’s Tower BFT protocol, these can be verified concurrently by separate validators, enabling parallelized computation.

On Polygon, the block size for the POS chain is currently between 50-120KB. There is a product in development called Polygon Avail that should increase this capacity. Avail is a data availability protocol that sits on top of the Polygon POS chain to increase storage. It is currently spec’d at 2MB per block with a 20 second block time though may scale to 128MB (with a theoretical minimum block time for a block that size of 5 seconds).

scaling

A one sentence summary of how Solana and Polygon differ on their approach to scaling would be: Solana is built to keep everything on a single chain and Polygon is built to add more concurrent chains that merge state periodically.

To expand on this, a Solana cluster (set of validators contributing to consensus) has a leader schedule. This leader schedule enumerates which validator will be verifying each block (a.k.a. a slot on Solana). With a predefined leader schedule, transactions are forwarded to the scheduled leader, cutting down on unnecessary coordination.

Potential Value Opportunities

Learning basic Ethereum Blockchain

Joshua Ellul 09:44 AM
It depends. If you have programming experience, then I would say find tutorials online and just get your hands dirty. You can use remix.ethereum.org which is an easy to use IDE to start trying out some smart contracts. There are also other languages supported by different platforms, e.g. cosmos: golang; substrate/polkadot: Rust; Neo/stratis: .NET; Algorand: Python and many more

If you do not have programming experience, I would recommend starting a programming course in a language like Python.

Joshua Ellul 09:46 AM
I had also written aa tutorial, that I tried to make as easy as possible to follow:
http://blockchainthings.io/article.aspx?i=2&t=1
http://blockchainthings.io/article.aspx?i=3&t=1
http://blockchainthings.io/article.aspx?i=7&t=1
http://blockchainthings.io/article.aspx?i=9&t=1
http://blockchainthings.io/article.aspx?i=10&t=1
http://blockchainthings.io/article.aspx?i=12&t=1
http://blockchainthings.io/article.aspx?i=13&t=1

Joshua Ellul 09:49 AM
There are also some smart contract platforms that allow for them to be created using templates (e.g. a web based interface), and no-code platforms. As well as some that allow for natural language (English etc) definition of smart contracts

Joshua Ellul 09:53 AM
I haven’t tried this, but it may be something to look into: https://transientnetwork.io/

Potential Challenges

Better DLT Software Governance, Quality and Productivity Needed

https://cointelegraph.com/news/programming-languages-prevent-mainstream-defi

smart-contract-gaps-2022-Programming languages prevent mainstream DeFi.pdf file

smart-contract-gaps-2022-Programming languages prevent mainstream DeFi.pdf link

Current Contract Languages, DLTs and DSLs come up short.

DAML has a DSL that comes up short on automation, events, control on quality, extensibility

Firefly is good in approach but has room for improvement in most areas

Fabric is mature in many DLT features compared to other chains but needs better integration w multiple identity models, CA services, smarter client request management ( via APIs ) and more

Governance is missing on smart contract review and testing ( think OWASP open source solutions but applied to Smart Contracts, Assets, Custody, Settlement and more )

Candidate Solutions

Step-by-step guide for Example

sample code block

Recommended Next Steps

Related articles