2. Motivation and requirement (300-400 words, 10 marks)

Tips:

1. Motivation is the reason why the authors propose the solution. It would

be the challenge of the domain. Normally, this can be found in the

abstract or introduction.

2. Functional/Non-functional requirements are typically summarised by

the author. But for the papers without an explicit summary of

requirements, you need to extract/derive requirements based on your

understanding of the problem/challenge described in the paper, the

design of the proposed system, and the domain.

a. When documenting requirements try to use keywords like

SHOULD, MUST, and MAY. See

https://www.ietf.org/rfc/rfc2119.txt

b. Requirements should be independent of the solution as much as

possible.

c. Requirements should be documented as complete sentences.

3. You don’t have to identify all requirements, just the core ones.

4. Suitability analysis is based on the framework learned in class and

tutorial.

5. It is highly advised that you look at guest lectures as they are on domains

that may give some background and pointers.

6. While each question has its word limit you don’t need to write each

answer to its fullest length.

2(a) What do the authors aim to solve? (2 marks – 0.5 x 4 points)

The paper is aimed to build a multi-tenant blockchain system with a scalable

platform architecture, which ensures data integrity while maintaining data

privacy and performance isolation.

2(b) What are the main requirements to be addressed while solving the

problem?

• Functional requirements (2 marks)

• Non-functional requirements (3 marks)

Functional requirements (2 marks – 0.5 x any 4 FRs)

FR1 – The platform should provide the function of writing data. The writing

permission is restricted to the platform owner.

FR2 – The platform should provide a cost-efficient writing function that

supports writing batches of data.

FR3 – The platform should provide a function to read all the historical

transactions/data.

FR4 – The platform should provide functions that allow end users to validate

the originality of the data (that is who wrote the data).

FR5 – The platform should provide functions that allow independent agencies

to access data for auditing for individual tenants.

FR6 – The platform should support multiple tenants to serve their end users

with different business requirements.

Non-functional requirements (3 marks – 0.75 x any 4 NFRs)

NFR1 – Integrity: Data integrity of item IDs added by a tenant must be

ensured.

NFR2 – Scalability: Scalability at the individual tenant level so that every

tenant could store a large volume of data within a period.

NFR3 – Scalability: Scalability at the platform level so that the platform could

support several tenants.

NFR3 – Data Privacy: A tenant must not be able to read data of other tenants,

like the unique item IDs created, scan event counts, timing, or locations.

NFR4 – Performance Isolation: The tenant with potentially higher workload

(e.g., commodity goods with millions of events daily) should not affect

read/write performance for other tenants.

2(c) Why is blockchain a good fit for solving this problem? (3 marks – 0.5 x any 5

aspects + 0.5 for decision)

• Is multi-party required? Laava’s scenarios deal with supply chains with

multiple parties. Every tenant is a party.

• Is operation centralised? Operation in this context can be loosely coupled

between multiple parties. But in the proposed solution the operation is

centralized and provided by the platform owner.

• Is immutability required? Transaction history and data immutability are

desired to enable traceability back to the origin of items and to control

fraud and substitution.

• Is high performance required? The time taken in Laava’s scenarios is

dominated by physical transportation and storage. There is no

requirement for extreme throughput or latency.

• Is data transparency required? Data transparency is required by the

parties within a tenant to support logistics planning and identify and

respond to problems. Data confidentiality is required between tenants.

Therefore, the given problem is suitable to be solved using a blockchain.

3. The overall design of the solution (~300 words, 10 marks)

Tips:

1. (Re)draw the main architecture diagram based on your understanding

of the system. You could remove some details from the original

diagram(s) or add more details if you think the original diagram doesn’t

cover enough details.

2. A technical architecture diagram with software components is expected

(rather than the use case, class diagrams, or sequence diagrams).

3. Consider making the component name bold to make the explanation

clearer.

4. Normally, you can find the explanation of all the components within the

proposed solution. If the interaction between components is not

articulated in the paper, use your judgement, and clearly state any

assumptions.

5. Try to use standard notations and make sure the diagram is clearly

visible and of high resolution (photo/scan of a diagram drawn on paper

is not recommended)

3(a) Draw a diagram of the proposed architecture and upload it here: (4 marks –

3 for key elements of diagram & connections + 1 for labelling)

• What are the components?

• How do the components interact?

• A legend is required

3(b) Briefly explain each of the components in the uploaded architecture

diagram and comment on them, for e.g., (6 marks – 1.5 x 4 components)

• If an existing blockchain is used? If not, what is the design of the new

blockchain?

• What is on-chain, and what is off-chain?

• What off-chain component is used (if any), and for what purpose?

In the proposed architecture, every tenant has an individual permissioned

blockchain to store their own data. The platform owner hosts the nodes with

writing permission to the permissioned blockchain for producing blocks while

the tenants/auditors host read-only nodes.

An end user sends write requests through the routing component, which

forwards the requests to the respective tenant’s blockchain to process. The load

balancer distributes the workload to the trigger components associated with

different writing nodes. The end user and auditor send read requests to the

read-only node through a public API.

Other than writing data to the permissioned blockchain, the trigger is also

communicating with the anchoring component, which queries the trigger to

get the Merkle tree root of the tenant’s permissioned. The anchoring

component connects to a node in the public blockchain network, and one node

for each tenant’s blockchain to be anchored.

A custom Merkle tree is designed, where the leaf nodes represent the root of

each tenant’s permissioned blockchain’s state Merkle tree. The custom Merkle

trees are stored on each individual blockchain and the root of the custom

Merkle tree is placed regularly on a public blockchain through the anchoring

component.

The anchoring protocol starts with querying the latest anchored Merkle root

stored on the public blockchain and verifying the Merkle root against the tree

maintained in the anchoring component to make sure the anchoring

component is up to date. For each tenant’s permissioned blockchain registered

with the anchoring component, there is a subprocess where the protocol

queries the blockchain Merkle roots on the latest block. If the chain is in the

Merkle tree of roots, the value for the leaf node is updated. If not, the chain is a

new tenant, a new node is added to the Merkle tree of roots.

4. Evaluation / performance analysis of the solution design (~250 words, 8

marks)

Tips:

1. Usually, you can find the evaluation section in the second half of the

paper.

2. You need to identify the methods used in the evaluation section and the

properties evaluated.

3. You need to summarize the setup/process of the experiment, and the

result of the experiment. Look for aspects like whether the solution was

simulated or had a real implementation, what types of data (real or

synthetic) and smart contracts were used, and how the data were

collected.

4. Identify the performance metrics and how they were measured.

5. Note your own observations from graphs and tables. Authors may not

discuss all findings though they may be in the paper.

6. Use your judgement in interpreting tables/graphs and clearly state any

inconsistencies you observe or any assumptions you make.

4(a) How is the proposed solution evaluated? (4 marks – 1 x 2 for method + 1 x 2

for properties)

• Methods: Experiment, simulation, case study, interview

• Properties: Security, reliability, cost, performance, etc.

The authors developed a research prototype for Laava company, which is a

third-party item tracking service provider. Laava provides a unique ID for

individual item tracking with various interesting features.

The proposed design is first examined against the identified requirements for

multi-tenant blockchain-based systems. Second, a qualitative analysis is

conducted by comparing the proposed architecture with two architecture

design alternatives, including one alternative using a global chain anchoring to

a public blockchain, and the other alternative using a public blockchain. These

three design alternatives are compared against data integrity, cost, data privacy,

performance isolation, availability, and configuration flexibility.

Third, a quantitative analysis is conducted by measuring the throughput of

unique ID creation under several conditions and evaluating the time of the

anchoring process.

4(b) What were the main findings from the results? (4 marks – 1 x 4 points)

For the throughput evaluation, 4 tests are designed, including normal load

scenario (<15tps), one tenant chain, boundary load scenario (~18tps), one

tenant chain, and overload scenario (~18-25tps), one tenant chain, and an

overload scenario with three tenant chains (~18-25tps on each chain). The

fourth test is aimed to investigate the performance isolation between tenant

chains as well as the anchoring protocol.

The results of the 4 tests show that the research prototype can register unique

IDs successfully and efficiently, and the performance is not impacted by the

increased number of tenant chains. For the performance of the anchoring

protocol, the total time from the start to the end of each anchoring round is

measured. The result shows that the anchoring times are not affected by the

load of the tenant chain.

5. Potential extensions (~250, 7 marks

Tips:

1. You might not find the answers to these questions in the paper. If at all

discussed, it is either under discussion or summary sections of the paper.

The questions in this section focus on your critical analysis of the overall

paper based on the material you learned in class.

2. Whether an answer is right or wrong depends on your arguments and

assumptions. So clearly state any assumptions.

3. In the case you find the “strengths” claimed by the authors in the paper,

it’s still ok to argue them as weaknesses. For example, you can argue that

using individual permissioned blockchain for each tenant increases the

complexity of the platform, resource utilisation, and maintenance cost.

4. Based on the arguments you build for strength/weakness, suggested

improvements can be different and again depend on arguments.

5. Limit your discussion to technical aspects relevant to the paper, e.g., do

not comment on the writing style of paper or clarity of figures. Also, for

a problem that does not need high throughput, it does not make sense to

suggest that authors improve throughput. Also, do not focus on aspects

that are not related to the class, e.g., problems with the use case.

6. No marks will be given to generic statements like increase throughput,

scalability, or reduce latency without a clear reason to do so and some

points on how it can be done.

5(a) Provide a critique of the paper: (4 marks – 1 x 2 for strengths + 1 x 2 for

weaknesses)

• What are the technical strengths of the proposed solution?

• What are the technical weaknesses of the proposed solution?

• Will the evaluation convince potential users to adopt the proposed

solution?

Strength

• Every tenant in the proposed solution has a dedicated permissioned

blockchain to maintain their own data and smart contract. Such a design

provides data privacy for the tenant.

• Using multiple blockchain rather than a global blockchain improves the

overall performance and scalability.

• Using permissioned blockchain rather than public blockchain could

minimize cost.

• Using a customized Merkle tree and anchoring with a public blockchain

can achieve data integrity for data with arbitrary size.

Weakness

• Writing operations to all the tenant chains is through the Laava platform,

which becomes a single point of failure from a software architecture

perspective. Although the routing component and load balancers can

mitigate the workload bottleneck from a technical perspective.

• The anchoring component is a centralized component, which is

maintained by the Laava platform. The whole anchoring process also

happens on the platform. Such central operation becomes a potential

single point of failure.

5(b) How would you improve the proposed solution? For e.g., (3 marks – 1 x 3

points)

• Replace a component to improve a property.

• Apply a design pattern to achieve a property.

• One potential improvement is to further decentralize the architecture by

allowing the tenants to maintain the writing operations by themselves.

To do this, tenants need to host their admin nodes with permission to

write data.

• Another potential improvement is to enable self-regulation through

implementing governance and regulation rules through the smart

contract.

• In the case of using a more decentralized architecture, multiple

authorization pattern could be applied when the cryptographic

representation on public blockchain needs to be updated.