A low level language, Serpent provides a superset of LLL. There’s not a great deal of information
for working with LLL, the following blog /var/log/syrinx and
associated lll-resurrected GitHub repository
is a good place to start.

In order to deploy a smart contract onto the Ethereum blockchain, it must first be compiled into
a bytecode format, then it can be sent as part of a transaction. web3j can do all of this for you
with its Solidity smart contract wrappers. To understand what is happening behind the scenes, you
can refer to the details in Creation of a smart contract.

Given that Solidity is the language of choice for writing smart contracts, it is the language
supported by web3j, and is used for all subsequent examples.

Compilation to bytecode is performed by the Solidity compiler, solc. You can install the compiler,
locally following the instructions as per
the project documentation.

To compile the Solidity code run:

$ solc <contract>.sol --bin --abi --optimize -o <output-dir>/

The –bin and –abi compiler arguments are both required to take full advantage of working
with smart contracts from web3j.

–bin

Outputs a Solidity binary file containing the hex-encoded binary to provide with the transaction
request.

–abi

Outputs a Solidity Application Binary Interface (ABI) file which details all of the publicly
accessible contract methods and their associated parameters. These details along with the
contract address are crucial for interacting with smart contracts. The ABI file is also used for
the generation of Solidity smart contract wrappers.

There is also a –gas argument for providing estimates of the Gas required to create a
contract and transact with its methods.

Alternatively, you can write and compile Solidity code in your browser via the
browser-solidity project. browser-solidity is
great for smaller smart contracts, but you may run into issues working with larger contracts.

You can also compile Solidity code via Ethereum clients such as Geth and Parity, using the JSON-RPC
method eth_compileSolidity
which is also supported in web3j. However, the Solidity compiler must be installed on the client
for this to work.

There are further options available, please refer to the
relevant section
in the Homestead documentation.

If you want to avoid the underlying implementation detail for working with smart contracts, web3j
provides Solidity smart contract wrappers which enable you to interact directly with all of a smart
contract’s methods via a generated wrapper object.

In versions prior to 3.x of web3j, the generated smart contract wrappers used native Solidity
types. From web3j 3.x onwards, Java types are created by default. You can create Solidity types
using the –solidityTypes command line argument.

You can also generate the wrappers by calling the Java class directly:

This will create a new instance of the smart contract on the Ethereum blockchain using the
supplied credentials, and constructor parameter values.

The <initialValue> parameter is only required if your smart contract accepts Ether on
construction. This requires the Solidity
payable
modifier to be present in the contract.

It returns a new smart contract wrapper instance which contains the underlying address of the
smart contract. If you wish to construct an instance of a smart contract wrapper with an existing
smart contract, simply pass in it’s address:

Using this method, you may want to ascertain that the contract address that you have loaded is the
smart contract that you expect. For this you can use the isValid smart contract method, which will
only return true if the deployed bytecode at the contract address matches the bytecode in the
smart contract wrapper.:

contract.isValid();// returns false if the contract bytecode does not match what's deployed// at the provided address

web3j provides a
TransactionManager
abstraction to control the manner you connect to Ethereum clients with. The default mechanism uses
web3j’s
RawTransactionManager
which works with Ethereum wallet files to sign transactions offline before submitting them to the
network.

However, you may wish to modify the transaction manager, which you can pass to the smart
contract deployment and creation methods instead of a credentials object, i.e.:

The RawTransactionManager takes an optional chainId parameter to specify the chain id to be used
on transactions as per
EIP-155. This prevents transactions from one chain
being re-broadcast onto another chain, such as from Ropsten to Mainnet:

In order to avoid having to change config or code to specify which chain you are working with,
web3j’s default behaviour is to not specify chain ids on transactions to simplify working with the
library. However, the recommendation of the Ethereum community is to use them.

You can obtain the chain id of the network that your Ethereum client is connected to with the
following request:

By default, when a new transaction is submitted by web3j to an Ethereum client, web3j will
continually poll the client until it receives a
TransactionReceipt,
indicating that the transaction has been added to the blockchain. If you are sending a number of
transactions asynchronously with web3j, this can result in a number of threads polling the client
concurrently.

QueuingTransactionReceiptProcessor
has an internal queue of all pending transactions. It contains a worker that runs periodically
to query if a transaction receipt is available yet. If a receipt is found, a callback to the
client is invoked.

NoOpProcessor
provides an
EmptyTransactionReceipt
to clients which only contains the transaction hash. This is for clients who do not want web3j
to perform any polling for a transaction receipt.

All transactional smart contract methods are named identically to their Solidity methods, taking
the same parameter values. Transactional calls do not return any values, regardless of the return
type specified on the method. Hence, for all transactional methods the
Transaction Receipt
associated with the transaction is returned.:

It provides details of the mined block that the transaction resides in

Solidity events
that are called will be logged as part of the transaction, which can then be extracted

Any events defined within a smart contract will be represented in the smart contract wrapper with
a method named process<Event Name>Event, which takes the Transaction Receipt and from this
extracts the indexed and non-indexed event parameters, which are returned decoded in an instance of
the
EventValues
object.:

EventValueseventValues=contract.processSomeEvent(transactionReceipt);

Alternatively you can use an Observable filter instead which will listen for events associated with
the smart contract:

Constant methods are those that read a value in a smart contract, and do not alter the state of
the smart contract. These methods are available with the same method signature as the smart
contract they were generated from:

When working with smart contracts you may want to specify different gas price and limit values
depending on the function being invoked. You can do that by creating your own
ContractGasProvider
for the smart contract wrapper.