Page 70 - Undergraduate Research Opportunities Program Proceedings 2017-18

School of Engineering
Department of Computer Science & Engineering

In the last series of this UROP research, we proposed a multi-level hierarchical framework that involves two roles of
smart contracts: Custodian and Client. Custodian contract has the ability to deploy on-demand Client contracts, retrieve
their data, and perform updates on Client contracts. On top of this, common states can be shared between Custodian
and Client contracts. However, as the types of interactions discussed previously were not as comprehensive as the
development of smart contracts become more rapid, this research serves as the extension of the hierarchical structure
proposed before, which put the main focus on comparing and contrasting all types of smart contract interactions, and
how they can be differentiated with our proposed framework. In this work, we hope to give more comprehensive
insights by introducing the interactions in a more thorough perspective.

Supervisor: HUI Pan / CSE
Student: WUU Cheng-hsin / COGBM Course: UROP1100, Spring

Smart contract has been widely used in different decentralized application. To execute a smart contract, user needs to
pay corresponding gas, which is proportional to the computational resources, to the miner. If all gas is consumed during
the execution, then the smart contract will fail and create the loss of gas as it will not be refunded. Thus, to avoid such
situation, one possible way is optimizing the gas cost of the smart contract. The optimization of gas cost comes from 3
different perspectives, operation-related cost, function-related cost, and code related cost. In this paper, Solidity is used
for conducting the research and analysis the factor of gas cost.

Supervisor: HUI Pan / CSE
Student: UY Mark Christopher Siy / MAEC Course: UROP1100, Summer

A smart contract is a blockchain-based technology that utilizes the decentralized, distributed, and immutable nature of a
blockchain in order to automate different transactions. The contract follows a set of ‘rules’, which is used to determine
the validity of a transaction. The contract itself is stored on the blockchain and can be ‘called’ on demand by individuals
or other contracts by accessing the said contract’s public methods and global variables. Now, while there have been
many promising developments that have arisen due to the advent smart-contracts, such as blockchain-enabled
decentralized applications. Smart contracts are far from perfect. This paper looks at a particular flaw regarding
Ethereum based smart contracts, with an emphasis on the cost of executing smart contract based transactions. This
paper implements a simple smart contract and presents a potentially large flaw in the way Ethereum charges gas for the
execution of transaction-operations, and correspondingly presents a solution to the said flaw. The solution, while
specific to the smart contract implemented, can serve as a framework for dealing with similar, but different cases. The
framework helps solve the problem of varying transactional costs due to variable or object initialization from a “zero”
value. All contracts are implemented using the Remix Web IDE and are deployed onto the Rinkeby and Ropsten test nets
using the Metamask browser extension.

Algorithms and Games in Android Devices

Supervisor: HUI Pan / CSE
Student: HUANG Yi-feng / SENG Course: UROP1100, Summer

The target of this project is to implemente a real time online database system that supports query and synchronization
of data for auction game in android device. The system incorporates relational database system (SQLite) for querying
and non-relational database system (Firebase Firestore) for online synchronization. The data is updated and stored in
Firestore in the cloud. And data is fetched to the local SQLite database for processing when executing query. Meanwhile,
a connection for keeping data updated is made to keep data in real-time. This structure may be extended to be used in
other projects that involves real-time extendable database.

60