See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/339019765

A blockchain-enabled e-learning platform

Article  in  Interactive Learning Environments · February 2020

DOI: 10.1080/10494820.2020.1716022

CITATIONS READS

54 3,798

2 authors, including:

Brijesh Dongol
University of Surrey
105 PUBLICATIONS   749 CITATIONS   

SEE PROFILE

All content following this page was uploaded by Brijesh Dongol on 09 February 2020.

The user has requested enhancement of the downloaded file.

A blockchain-enabled e-learning platform

Tsz Yiu Lama* and Brijesh Dongola,b

Brunel University London, Uxbridge, United Kingdom; bUniversity of Surrey, Guildford, United
a

Kingdom

*Correspondence: Tsz Yiu Lam Email: dtylam@protonmail.com

A blockchain-enabled e-learning platform
The properties of a blockchain such as immutability, provenance, and peer-executed
smart contracts could bring a new level of security, trust, and transparency to e-
learning. In this paper, we introduce our proof-of-concept blockchain-based e-
learning platform developed to increase transparency in assessments and facilitate
curriculum personalisation in a higher education context. Most notably, our platform
could automate assessments and issue credentials. We designed it to be
pedagogically neutral and content-neutral in order to showcase the benefits of a
blockchain back-end to end users such as students and teaching staff. Our evaluation
suggests that our platform could increase trust in online education providers,
assessment procedures, education history and credentials.

Keywords: E-learning; blockchain; distributed ledger; smart contracts; Hyperledger;

assessment; trust; transparency; privacy; higher education

1. Introduction
The advent of cryptocurrencies has shown off the power of the underlying technology,
blockchain, which is set to make significant disruptions in industries ranging from financial
services to supply chain management and identity management (Bessonov, 2017).
Blockchain 2.0 refers to blockchains that are capable of running smart contracts, which are
self-executing programmes embedded in blockchains (Swan, 2015, p.9) that defines an
agreement and automatically enforces obligations through the exchange or transfer of
digital assets when certain conditions are met (Gulhane, 2017).
Smart contracts can be very powerful because they can be Turing-complete, which is the
case for popular platforms such as the Ethereum blockchain and Hyperledger
distributions, which allows user-defined machine states and arbitrary computations (Dinh
et al., 2018), capable of running any user-defined code.
The potential of smart contracts in e-learning has been noted by the community, with
Swan (2015, p.62) proposing that “learning smart contracts could automatically confirm
the completion of learning modules through standardized online tests”. Blockchain
technologies and smart contracts can also benefit developing countries or markets,
providing trustworthy processes and ownership (Underwood, 2016). This in e-learning
could translate into more trustworthy education credentials, more mutual recognitions
and a globalised, borderless higher education sector (c.f., Odem.IO (2018)).
This paper describes an application of blockchains and smart contracts in e-learning. We
explore issues in higher education and e-learning that can be improved by a blockchain-
based system, and introduce our proof-of-concept platform called “Blockchain University”
developed as part of the first author’s final-year project. We will start by offering some
essential, contextual information on blockchain technologies below:

Blockchain technologies
A blockchain (also called a distributed ledger) is a type of database that is spread across
multiple sites, such as different institutions or companies. A block of records is chained to
the next with a cryptographic signature, then added to a timestamped list of blocks
through a consensus corroborated by all network peers (Walport, 2016, p.17). It only
allows the insertion of transactions, not the update or deletion of existing transactions.
This ability to prevent tampering is known as immutability (Xu et al., 2016, p.182).
 The verifiability of all timestamped actions on a blockchain gives systems an inherently
high degree of integrity and transparency, often ensuring the authenticity and ownership
(also called provenance) of digital records or goods (Walport, 2016, p.7). Some types of
blockchain can also have permissions that enable granular transparency and privacy
(Walport, 2016, p.22), which fits well in the education paradigm where personal data can
be highly sensitive.
Blockchains can be classified into two types: one being a permissionless (public)
blockchain that anyone can use and no central authority exists to allow or ban peers; the
other a permissioned blockchain (can be public or private) where a central entity assigns
read/ write rights to individual peers (Wüst & Gervais, 2017, p.1). Table 1 summarises the
main differences between these two types of blockchains.
Table 1. Comparison of permissioned and permissionless blockchains, modified from
Wüst and Gervais (2017, p.3)

Properties Permissionless blockchains Permissioned blockchains

Speed Low throughput and slow high throughput and medium

latency latency
Peers High number of both readers High number of readers, small
and writers group of writers
Consensus Proof of work or proof of stake Practical Byzantine Fault
by miners Tolerance (PBFT) protocols,
tolerating malicious peers and
trusting the majority consensus
Central No Yes
Authority
Privacy Can be achieved using Reading rights can be restricted
cryptographic techniques but by central authority, readers and
typically comes at the cost of writers can also run separated
lower efficiency parallel blockchains that are
interconnected
Verifiability Observers can verify the state of the blockchain

Redundancy High, provided through replication across the peers

Using blockchains as a data storage mechanism gives our system a very high degree of
integrity. The public verifiability, redundancy and immutability of the blockchain makes it
very difficult to corrupt or lose the data stored.

Smart Contracts
Smart contracts are self-executing programmes embedded in a blockchain that defines the
rules and penalties around an agreement, enabling automatic enforcement of obligations.
They can reduce administrative efforts and save time, and prevent disagreements about
transactions (Gulhane, 2017). There are three main properties that characterise smart
contracts (Swan, 2015, p.16).

• Autonomy: after launching and running, no further communication is required

between a smart contract and its initiating agent.
 • Self-sufficiency: a smart contract should have the ability to keep itself alive when it
needs to be, such as raising funds by providing services, and spending them on
computing power or storage.
• Decentralisation: a smart contract does not exist on a single server, they are
distributed and self-executing across all of the blockchain peers.

These properties ensure the effective operation of smart contract programmes. In an e-

learning context, this can potentially be used to govern how teaching, evaluation and
feedback take place, enhancing protection for the learners. It could also automate more
administrative work and reduce manual errors.

Overview
Blockchain University fulfils educational assessments and personalised curricula with
smart contracts on a public permissioned blockchain. It showcases the potential of this
emerging technology in improving several core learning experiences, namely assessments,
curriculum personalisation, and learner privacy. It was able to build more trust in
education processes and credentials by increasing transparency and provenance, while
still offering fine-grained access controls on student records. For the latest version of the
system code, please visit https://github.com/dtylam/bcu, and for a demonstration video,
please see https://www.youtube.com/watch?v=MP5jSItMenI.

Section 2 explores some of the issues in higher education and e-learning that can be
improved by a blockchain-based system. Section 3 follows on to describe the design of our
Blockchain University platform, its blockchain, applications, and services. Section 4
displays and explains the results of our user study, eliciting feedback on the demonstrator
system from students and teachers. Section 5 gives some conclusion and ideas for future
work.

2. Motivation: E-learning challenges

Frameworks and structured architectures that support e-learning platforms have
continued to evolve (see García-Holgado and García-Peñalvo (2016); Gros and García-
Peñalvo (2016), which provided surveys). In this section, we highlight some of the main
issues addressed by our system. Section 2.1 covers assessments and transparency, Section
2.2 discusses curriculum diversification and Section 2.3 covers the provenance of
credentials.

2.1. Transparency in Assessments

Assessment is arguably the most important process in the business of education as it can
“drive what is learnt and taught” and “converts learning into credentials” (Campbell,
2010, p.160). However, tension and mistrust can exist between an educational provider
and learners due to a lack of transparency of assessments. Brown Jr (1999, p.62) described
there to be “abundant evidence that assessors are not particularly good at making exams
valid, reliable, or transparent to students”. Suhre, Jansen, and Torenbeek (2013) collected
data from 168 first-year university students for six months about their motivation to study,
and found three main factors: intrinsic abilities, personal motivations (such as a need to
achieve or fear of failure), and transparency in assessments. The earlier Bryan and Clegg
(2006, p.100) research echoed the same findings, i.e., students realise their full potential
when they understand the assessment task, marking criteria and expected standards.
We were interested in the independent variables which improved transparency in
assessments, which could be translated into features for our system. The two studies
above recommended that institutions and teachers should provide to learners:

• clarity on assessment goals,

• what knowledge is required for a sufficient level of mastery,
• clear procedures for assessing these goals,
• marking criteria and expected standards,
naming these as key factors to increasing transparency in assessments. The provision of
these information made significant improvements in higher education courses (Suhre et
al., 2013):
• Students’ perceptions of degree programme organisation and transparency of
exams are significantly correlated with academic performance;
• Academic pressure is substantially influenced by the perceived transparency of
assessments.

An e-learning system could enforce the mandatory provision of the above information that
increases transparency in assessments.
A blockchain-enabled e-learning system could go further: smart contract
programmes could run assessments based on pre-defined rules, regulations, goals, and
rubrics, especially where marking is done with or aided by code.
Assessment procedures such as manual marking, double marking, moderation and
appeals could also be visible and verifiable on the blockchain. This could directly tackle
some of the negative sentiments on the validity, reliability, and transparency of
assessments from Brown Jr (1999).

2.2. Curriculum Diversity and Personalisation

Higher education trends indicate an increase in interdisciplinary research, teaching and
student degree offerings — both within a single institution and between two or more
institutions, such as the Universitas 21 network and the Semester Online consortium
model (Jacob, 2015, p.4).
Alammary, Alhazmi, Almasri, and Gillani (2019, p.14) proposed that a main area
where blockchain can be of great benefit is collaboration and partnership between
educational institutions. It has been trialled by different educational institutions as a
secure and reliable ledger to record their students’ academic achievements.
The added level of transparency and trustworthiness in both course content and
assessments from blockchain technologies could accelerate mutual recognition of courses
and credentials between education providers. A future borderless e-learning marketplace
could provide maximal diversity in knowledge by creating an open, global course
catalogue that is interdisciplinary and cross-institutional.
The personalisation of education curriculum for learners helps “overcome barriers,
raising self-esteem and achievement” (Condie & Munro, 2007). Research points to a
growing appreciation of the need to support and encourage learner control over the
learning process (Dron, 2007).
 By presenting an online degree/ curriculum as a peer-executed smart contract that
learners can personalise and negotiate, the increased learner control and freedom could
increase motivation.

2.3. Provenance of e-learning credentials

Online learning credentials are still popularly questioned and regarded as inferior in both
developed countries and developing countries (Andersson & Grönlund, 2009, p.7). In the
US, less than one-third of university faculties accept the value and legitimacy of online
education, a percentage that has changed little over nine years. (Allen & Seaman, 2013,
p.6).
Accountability and transparency are important especially in higher education,
which subscribes to an audit-based quality control lifecycle (Hoecht, 2006). Employers
have a vested interest in what is assessed and the fairness of assessments in education,
because it affects the recruitment of employees (Brown, 1999, p.58).
By packaging assessments into smart contracts, a blockchain-based system can run
assessment procedures, and any outside observer can read these smart contracts and
become familiar with the processes of credential generation and which assessments they
were based on. This provides a channel for accrediting agencies to verify information
provided by educational institutions as well, and could contribute to the improvement of
online education quality (Alammary et al., 2019, p.15).

Existing Projects
Several blockchain-based projects for education already exist. We consider three of these in
detail: Blockcerts, Sony Global Education (GED) Blockchain, and the OpenLearn
Blockchain from the Open University. See Table 2 for an overview.

Table 2. Comparison of existing projects: Blockcerts from MIT Media Lab (blockcerts.org,
2018), Sony Global Education Blockchain (Sony Global Education, 2017), and the
OpenLearn Blockchain from Open University (Open University, 2018)
Project (Based on) Features
Blockcerts Education providers can store a batch of certificates by paying
(Bitcoin) for a bitcoin transaction, storing data in the OP RETURN
transaction field on the global bitcoin blockchain.
Sony GED Developers at education institutions can use their application
Blockchain programming interface (API) to securely store learning history
(Hyperledger data and certificates, integrating with third-party e-learning
Fabric) systems.
OpenLearn An experimental plugin for Moodle, a popular course
Blockchain management system, has been developed. Achievement badges
(Ethereum) can be stored on the Ethereum blockchain. Students can register
for courses and receive badges in a “Student Learning
Passport”.

All of the three notable projects hash certificate information onto a blockchain. This
can improve trust in these certificates and reduce degree frauds (Chen, Xu, Lu, & Chen,
2018). However, institutions still generate and issue these credentials in a relatively black-
box process. Smart contracts that govern the end-to-end learning journey from course
registration, assessment attempts, to credential generation, would offer a degree of
provenance much higher than that of these existing tools. This high degree of provenance
and content transparency could even enable the auditing and quality control of new
education providers.
Our platform (see Figure 1) aims to extend these efforts by using smart contracts to
automate and expose assessments procedures facilitate the negotiation of personalised
curricula, and generate credentials.

Teacher hash Teacher defnes Assessment

assessment smart contract
certifcates in contracts for
a transaction their courses (eg. automated marking)

Results & Certifcate when

Feedback completed

blockchain blockchain

Verifcation Student adds Verifcation

Service submission for Service
an assessment
for consumers for consumers
(eg. employers) (eg. employers)

Blockcerts Blockchain University

Figure 1. Comparison between existing efforts (eg. Blockcerts) and our assessment smart
contracts concept

3. The Blockchain University e-learning platform

In this section, we describe the design and development of our platform, addressing the
challenges reviewed in Section 2. Figure 2 offers an overview of the technical architecture
of our Blockchain University platform and demonstrator system, which provides client
applications and additional services that interact with the blockchain. The applications
and services communicate with the blockchain via REST-ful (Representation State
Transfer) web APIs (application programming interfaces): using HTTP(S) and the popular
JSON data format (Bülthoff & Maleshkova, 2014).
 External
Content Delivery
Learner Services
Application
Smart <>
Contracts

Hyperledger
Teacher Simple Testing
REST Composer REST
Application Service
Layer

Assessment Services

Hyperledger Other
Reader
Fabric Automated
Verification
Blockchain Marking
Application
Services

Client Applications Blockchain/ Ledger Client Services

Figure 2. Component architecture overview of the demonstrator system built (components

in dashed line boxes were not built)
We first explain our choice of blockchain distribution (Section 3.1), then discuss the
design of our blockchain schema (Section 3.2), smart contracts (Section 3.3), and
applications for learners and teachers (Section 3.4).

3.1. Selection of blockchain distribution

As discussed in Section 1, there are several different subcategories of blockchain
technologies, such as permissioned vs. permissionless, and private vs. public. Wüst and
Gervais (2017, p.3) have proposed a decision flowchart (Figure 3) to determine whether a
blockchain is an appropriate solution for a given problem, and which type of blockchain is
the most appropriate. The analysis of our context with the decision flowchart steps are as
follows:

Are there Can you No Are all No Permissionless

Do you need Yes multiple Yes use an always writers
to store state? known? Blockchain
writers? online TTP?

Yes

Are all No Is public Yes Public

writers verifiability Permissioned
trusted? required? Blockchain
No No No

Yes
No

Don’t use Private

Blockchain Permissioned
Blockchain

Figure 3. The “Do you need a blockchain?” flowchart (Wüst & Gervais, 2017, p.3)
 (1) Do you need a store state? Yes. Records in an e-learning system require secure
storage.
(2) Are there multiple writers? Yes. There are many different authorities, institutions,
educators and learners involved in an e-learning blockchain all of whom demand
write access to records.
In an e-learning context, different writers must have different levels of access; this
issue is discussed in more detail below.
(3) Can you use an always-online Trusted Third Party (TTP)? Wüst and Gervais (2017, p.2)
described two options of using a TTP: delegate write operations completely to the
TTP if it is always online so that it verifies all state transitions, or use a not always-
online TTP as a certificate authority in the setting of a permissioned blockchain.
In the e-learning context, a TTP could be the e-learning platform provider.
However, the delegation of write operations to the platform goes against modern
principles of autonomy and independence for higher education institutions. Most
real-world central authorities such as government education ministries regulate
and audit higher education institutions without writing student records or
conferring degrees. An always-online TTP should not be used in order to replicate
the real-world context. This paper will answer no for this step.
(4) Are all writers known? Yes. Users of the system should be registered and not be
anonymous to the system administrators. For example, education credentials
should be awarded to a real person.
(5) Are all writers trusted? No. Malpractices from education institutions can occur,
especially in the private, for-profit sector. In a future open e-learning market, it
could also be possible for anyone to start offering education services. We cannot
assume that all writers are trusted.
(6) Is public verifiability required? Yes. One of the objectives of this project is to increase
the trustworthiness of e-learning credentials by increasing public verifiability of
education journeys, increasing public accountability especially to stakeholders such
as employers and postgraduate studies providers.

Thus, this process leads to a public permissioned blockchain. We chose Hyperledger

Fabric, an open source public permissioned blockchain distribution that is supported by
the Linux Foundation and IBM. Further refinements to the design were carried out within
Hyperledger Composer, a development framework that accelerates time-to-value for
blockchain projects. It offers business-centric abstractions such as rapid prototyping of use
cases, and can deploy definition files (The Linux Foundation, 2018a) from design stages
directly to a Hyperledger Fabric blockchain. These definition files include:

• an object-oriented modelling language file to define the blockchain schema,

• a script file to define the programming logic behind available smart contracts, and
• an access control language file to define access rules for blockchain records.

We provided a high-level overview of these designs below. Full details of the data
models and smart contracts can be found at the GitHub repository
(https://github.com/dtylam/bcu).
3.2. Design of blockchain schema
Similar to a conventional database, a blockchain requires a schema that describes how data
should be organised. The schema can also be used to describe relationships between
records (such as inheritance). This schema is populated across the network and used by all
peers. Once established, a blockchain schema cannot easily be modified, requiring a fork
on a permissionless blockchain (Lin & Liao, 2017), or a backward compatible update on a
permissioned blockchain (The Linux Foundation, 2018b).
Our schema contains data objects, defined in an object-oriented programming
paradigm, inheriting parent objects such as participants (objects corresponding to peers/
actors on the blockchain) and assets (objects corresponding to any tangible/ intangible
goods tracked by the blockchain).

Participants
Our network allows the creation of three main types of participants (see Figure 4):

• Teacher, which can be lecturers, teaching assistants, tutors, etc.

• Learner, which can be campus students, distance learners, etc.
• Reader, members of the public who are interested in querying or verifying records,
such as employers and further education providers.

User
uid = 123
nam e = " John Doe"
nid = " DOE123456ABCDEF"
St ring organisat ion

Learner
CourseModule[ ] m ods
Subm ission[ ] subs Teacher Reader
Cert ificat e[ ] cert s
CourseModule[ ] m ods
Double balance
Int eger[ ] accessLevels
St ring[ ] privilegedReaderIds

Figure 4. Class diagrams of participant objects on our blockchain

Mandatory access control rules were in place to ensure that records on the
blockchain are created, updated and read by only the appropriate participants. For
example, a learner can only propose curriculums for themselves, and a teacher can only
submit grades for courses they are teaching, etc.
In the same way that conventional databases can store user settings data, a
blockchain could also store values that enable discretionary access control rules. For
example, our demonstrator system provides tiered access-control to learner information by
asking learners to set a level of privacy (the acLevels field) and a list of privileged readers
who can see more of their records (the privilegedReaderIds field). See Appendix A for
further details on the access control rules for our blockchain.
Assets
The asset objects were modelled with fields from literature that could address our e-
learning challenges. They were not designed to be exhaustively feature-rich, but just to
support a minimally viable system that could demonstrate our design advantages.
See Figure 5 for the detailed fields of these asset objects:

• Curriculum: a set of courses chosen by a learner;

• CourseModule: a course created by a teacher;
• ModuleUnit: a CourseModule is made up of many of these units;
• Assessment: a ModuleUnit could contain an assessment;
• Submission: a submission is created by a learner for an assessment;
• Certificate: a certificate is issued by a teacher to a learner for the completion of an
Assessment, a CourseModule, or a Curriculum.

CourseModule Subm ission Assessm ent

St ring m odId
Teacher[ ] t eachers
CourseModule[ ] prerequisit es
CourseModule[ ] corequisit es
Cert ificat e cert (opt ional)
St ring m odTit le
Double cost
St ring[ ] learningObject ives
ModuleUnit [ ] unit s
ModuleUnit
St ring unit Id
CourseModule m od
St ring unit Tit le
St ring m at erialMd
Assessm ent assessm ent
St ring assessId
St ring subId
ModuleUnit unit
Learner learner
Boolean t erm inal
Teacher t eacherAssigned
Int eger weight ing
ModuleUnit unit
St ring result Type
St ring cont ent
St ring[ ] knowledgeRequired
St ring com m ent s
GradeDescript or[ ] gradeDescript ors
Dat eTim e t im eAdded
MarkingCrit erion[ ] crit eria
Dat eTim e t im eAssessed
Int eger passingSt andard
Assessm ent Result result
St ring det ailsMd

Curriculum
Cert ificat e
St ring currId
St ring cert Id
Teacher t eacher
Learner learner
Learner learner Aut oAssessm ent
Teacher[ ] signat ories
Cert ificat e cert
Curriculum curriculum (opt ional) St ring t est Type
CourseModule[ ] m ods
St ring[ ] subIds St ring t est File
St ring curTit le
Assessm ent Result overallResult
St ring not es
St ring organisat ion
St ring program m eOut com e
St ring fineprint Md
Boolean approved

Figure 5. Class diagrams of asset objects on our blockchain

Note that even though CRUD-based operations (Create, Read, Update, and Delete)
will be used to describe interactions with these assets on the blockchain, the only possible
operations on the blockchain are just Read and Append, where an asset is marked as
created, updated, or deleted in a newly appended record.

3.3. Design of smart contracts

Smart contracts can be viewed as a collection of transaction scripts, similar to stored
procedures in relational database management systems (Christidis & Devetsikiotis, 2016).
Transactions on the blockchain can trigger relevant sections of a smart contract
programme, and is the only activity a peer can perform to alter the state of a blockchain.
The pre-defined script would run on blockchain peers, and propose changes to the
blockchain. The changes are accepted by the network if consensus is achieved. Once
accepted any changes are irreversible.
Algorithm 1 presents a simplified structure of a transaction script in the
Hyperledger Composer environment we used. Each transaction takes a set of inputs then
performs checks on the contract terms based on these inputs and state of the blockchain. If
the checks are validated, assets on the blockchain could be created or updated as per the
contract terms via network consensus, otherwise the transaction is simply rejected.
Algorithm 1. Simplified structure of a transaction script in Hyperledger Composer
transaction tx(inputs)
if contract terms are fulfilled then
... ← create/ update blockchain object(s)
return Transaction Accepted ← if network consensus achieved
else
return Transaction Rejected
end if
end transaction ← do nothing if contract terms not met

A smart contract typically comprises several such transactions. In addition, they may
define and manage other components that are stored within a blockchain. This may
include (Christidis & Devetsikiotis, 2016):
(1) Assets held by the contract: assets are placed under the control of the smart contract
programme to be read or updated automatically;
(2) Contract terms: a set/ sequence of transaction operations, with custom transaction
code/ scripts that check for conditions and handle exceptions.
(3) Digital signatures: participants could sign contracts (authenticate their transaction
requests) with their private keys.

To build our proof-of-concept system, we modelled the curriculum personalisation

and assessment use cases into two smart contracts, each of which contained five
transactions (see Figure 6 for an overview). We discuss these in the subsequent
subsections.

Figure 6. The curriculum and assessment smart contracts, and the transactions, where the
optional SignCertificate transaction could be part of both smart contracts, as certificates
can be released for curriculum/ course

3.3.1. Curriculum personalisation

Our intention is to make use of a blockchain-based system to enhanced flexibility in
curriculum design, increase transparency and trust amongst institutions and employers,
and deliver a more diverse set of learning outcomes. Blockchain University is designed to
be a global blockchain shared by institutions, with a cross-institutional course catalogue. A
learner would be free to select courses from any discipline and any institution. Therefore,
we introduce the learner into the curriculum development process and course selection
takes place as a negotiation loop, where the learner and teacher submit suggestions back
and forth. An overview of this use case is provided in Figure 7 using UML (Unified
Modeling Language) notation, where two transactions were developed to fulfil the
curriculum contract.
The first is the PROPOSECURRICULUM transaction (pseudocode in Figure 8, top)
which can be requested by either a learner or a teacher. When invoked, the transaction
performs a number of checks. For example, our demonstrator checks whether
prerequisites are met and the number of available credits. Institutions can write further
policies if required. If any of these checks fail, the transaction is rejected. These checks
would be peer-executed and the results of the transaction would create or update the
curriculum based on the peer consensus.

Learner Blockchain Teacher

ProposeCurriculum ()

CREATE Curriculum

loop [ N e g ot ia t ions]
ProposeCurriculum ()

UPDATE Curriculum
ProposeCurriculum ()

UPDATE Curriculum

ApproveCurriculum ()

UPDATE Curriculum, Learner ;

CREATE Cert ificat e(s)

Figure 7. Sequence diagram denoting transactions (blue arrows) in the curriculum

personalisation use case
Figure 8. The PROPOSECURRICULUM and APPROVECURRICULUM transactions in the
curriculum smart contract
In the future, smart contracts could even automatically resolve curriculum
negotiations, with more advanced versions developed that takes into account a learner’s
academic and technical background, and automate administrative or regulatory steps
required for institutions.
The second transaction, APPROVECURRICULUM (pseudocode in Figure 8, bottom),
was designed for the teacher to accept a proposed curriculum. It automatically:

• enrols the learner to the list of courses: deducting credits from the learner’s balance,
and associating the Curriculum asset with the Learner.
• creates dormant certificates that are unfulfilled and unsigned, which means they
are empty Certificate assets that are not yet supported by any Submissions assets,
nor signed as “awarded to the learner” by any teachers.

The distributed storage of curriculum records and dormant certificates across the
blockchain means that blockchain peers can independently run smart contracts that
process assessment attempts, confirm their outcomes, and release certificates
automatically. The transparency and peer-executed nature would enhance the
trustworthiness of the certificates.
3.3.2. Assessment
Our proof-of-concept demonstrator platform enables assessments to be carried out within
the blockchain. Assessments running on smart contracts are peer-executed: peers on the
blockchain network will run the same calculations and achieve a consensus over what the
resulting final grade is, reducing greatly the chances of tampering. By formalising
assessments into a series of transparent steps executed by a peer network, we hope to
encourage teachers to operate assessments with increased transparency, and formally
record adjustments or discretionary measures, which could reduce tension and
disagreements between teachers and learners.
We considered two different forms of assessments: assessor marking and automated
marking. Assessor marking refers to the traditional process of a teacher grading a learner’s
work using their professional judgement. This form of marking accommodates any
standard marking scheme; the difference here is that marks are submitted electronically
and recorded in the blockchain. Automated marking refers to machine executed tests that
provide results and feedback to an assessment. It has the capability of reducing manual
workload and can offer instantaneous feedback. Such forms of marking have risen in
popularity, particularly within fields such as Computer Science. Studies have shown that
automated assessments with highly granular marking schemes and feedback units can be
highly effective and motivating (Falkner, Vivian, Piper, & Falkner, 2014).
Mandatory information would be solicited from the teachers when they upload
their courses in the CREATEMODULE transaction, where they have to offer descriptions of
their assessment tasks on:

• Assessment goals (e.g., assessment goal statements, knowledge-required

statements)
• Assessment procedures (are the assessments automatically marked by code, or
manually marked by assessors?)
• Assessment rubric (e.g., marking criteria, weighting, grade descriptors, details of
automated tests)

These fields were constructed based on the aforementioned research findings in

Section 2.1. They are visible to all learners and readers at all times and are also the input
parameters for the smart contract programme.
Two transactions were designed to fulfil our assessment smart contracts; their
interaction is outlined in Figure 9. For both the ADDSUBMISSION (pseudocode in Figure 10,
top) and SUBMITRESULT (pseudocode in Figure 10, bottom) transactions, if a Submission
asset has been updated with a passing grade, pointers to the Submission will be added to
the relevant Certificate assets as evidence of assessment fulfilment.
 Learner Blockchain Teacher

AddSubm ission()

CREATE Subm ission

a lt [ Aut om a t e d m a r k ing ]

Sm art cont ract sends

pre-defined t est file(s),
and subm ission file(s), Aut o Marking API
t o m arking service and
st ores result s

[ Asse ssor m a r k in g ]
Grades st ored and
calculat ed by sm art
Subm it Result ()
cont ract according t o
pre-defined rubric

UPDATE Subm ission, Cert ificat e

Figure 9. UML sequence diagram denoting transactions (blue arrows) for an assessment
attempt
 Figure 10. The ADDSUBMISSION and SUBMITRESULT transactions in the assessment
smart contract

The ADDSUBMISSION transaction is requested by a learner to store a submission

(assessment attempt) on the blockchain. Storing submissions on the blockchain network
ensures the submission is secure and immutable. In our demonstrator system, files are
compressed and converted into base64 data strings. In practical scenarios where the
uploaded files would be too large, a file server could be used to store submissions, and a
checksum stored on the blockchain instead.

Automated Marking
The ADDSUBMISSION transaction could immediately return the results of automated
assessments. Automated marking test files are transparently stored on the blockchain, to
be sent together with learners’ submission files to the designated external automated
marking services.
In our demonstrator system, only one simple automated marking service was built.
It was a separate web application that runs a string equivalence test. Even though this was
just a simple equivalence test, it showcased the blockchain’s ability to conduct automated
tests. More sophisticated assessment APIs could be called in the future, and existing
assessment technologies such as plagiarism checkers, code testing/ analysis in computer
science education can be leveraged.

Assessor Marking
The SUBMITRESULT transaction is requested by the teacher of the course to update the
assessment result of a submission on the blockchain for assessor marking assessments.
There are several possible ways in which grades could be calculated: by the teacher, by the
application, or by the smart contract on the blockchain. In our system, we choose to
develop the last of these since the grades calculation formula would already be stored on
all blockchain peers in the pre-defined assessment rubric.
Teachers are able to submit marks against a grade descriptor grid. Final grades are
calculated by smart contracts according to the pre-defined weightings and rules. Teachers
could then make adjustments to the final grade with comments. This provides a
mechanism for more transparent grade moderation.

3.3.3. Credential generation

As discussed in Section 2.3, the presence of course enrollment and assessment transactions
on the blockchain offers a trustworthy, immutable view of a learner’s journey. The
credentials generated by our platform are always provenanced by these previous
transactions, which can be validated by anyone, and made readable to anyone if the
learner wishes.
An optional SIGNCERTIFICATE transaction was designed to let teachers explicitly
sign and endorse a certificate on the blockchain. This is to mirror the formal “degree
conferral” processes in real-world universities, and serves as a final step for any manual
due diligence before the certificate for a curriculum or a course is awarded to a learner.
Depending on the design of the curriculum or the course, it could require multiple
signatures.

3.4. Client applications

This section will discuss the design considerations made when creating the example client
applications for Blockchain University. Two client applications were created for the
platform: one for learners and one for teachers. A video demonstration showcasing typical
user journeys across both applications was created
(https://www.youtube.com/watch?v=MP5jSItMenI).
Example data was created and imported onto the blockchain. These were created
by loosely following the syllabuses of courses from several MOOCs (Massive Open Online
Courses) on EdX and Coursera offered by universities.

Support for curriculum personalisation

Green, Facer, Rudd, Dillon, and Humphreys (2005) have summarised several areas pivotal
to enabling personalised learning through digital technologies. Blockchain University
applications followed three of these recommendations:

• Ensure that learners are capable of making informed educational decisions: learners
can access direct messages with their tutors and advisers from the Curriculum
planning interface.
 • Diversify and recognise different forms of skills and knowledge: learners can access
a global catalogue of courses from different institutions and consider adding them
into their curriculum.
• Include learner focused forms of feedback and assessment: this is encouraged by
the feedback fields in the AssessmentResult data object.

The user interface for these features was built as shown in Figure 11.

Figure 11. The “My Curriculum” personalisation page in the learner application

The assessment contract experience

Users are introduced to the concept of a smart contract in the application interface, where
an assessment is presented as a “contract”, where the assessment properties (as discussed
in Section 3.3.2) are displayed transparently as they attempt and submit their work. See
Figure 12 for a screenshot.
The platform will notify the learners of their progress, results and feedback, which are
returned by the smart contracts.
 Figure 12. Learner Application example Assessment Contract page

Usability and learnability

Care was taken to maximise usability and learnability of these applications, as a poor user
experience may adversely affect the stakeholder feedback study we have carried out next.
To improve learnability, the applications adopted Google’s popular “Material
Design” visual design language, used by many web and mobile applications. User
familiarity with this popular user interface framework should increase the learnability of
this new application and the discoverability of its features (Sadana, Agnihotri, & Stasko,
2018).

4. Stakeholder feedback study

We conducted a qualitative study with potential users to help reach preliminary findings
on the effectiveness of a blockchain-enabled e-learning system.

Participants
We recruited four participants through convenience sampling within the institution, by
directly approaching known stakeholders. Two of the participants were experienced
teaching staff, and the other two were higher education students with academic liaison
experience, such as being course representatives, or peer-assisted learning leaders,
therefore well-exposed to a wide range of student problems.

Procedure
A total of four semi-structured, face-to-face interviews were conducted in March 2018.
Participants were shown a demonstration of both client applications for learners and
teachers, and invited to explore platform features hands on.
Participants were then asked to rate the system by answering several structured
questions with a Likert-type scale, designed to better draw conclusions on the aims and
objectives of the demonstrator system. The inclusion of the structured responses was to
encourage participants to express a positive/ negative opinion about the guiding
statements, not for quantitative analysis.
Participants were asked “How and Why?” after each of the structured responses,
and a final informal discussion of any follow-up questions would wrap up the interview.
The raw data from interview transcripts were later analysed and grouped using thematic
analysis techniques.
Table 3. Participant responses to structured questions from the stakeholder feedback study
Statement Responses

1 The features of the system communicate assessment expectations 3 5 4 4

well
2 The features of the system improve transparency in assessment 3 5 5 5
procedures
3 The features of the system make curriculum personalisation 5 5 5 4
convenient
4 The system provides good (administrative/ pastoral) support for 5 5 4 3
curriculum personalisation
5 The system can reduce tension and disagreements between 4 3 3 4
educators and students
6 The system makes educational history more transparent and 5 5 3 5
trustworthy
7 The access control features of the system preserve student privacy 4 5 5 5
8 The system increases the trustworthiness of online education 4 5 4 4
providers and credentials

4.1. Findings
Throughout the demonstrations held, a lot of time and effort had to be put in describing
what a blockchain is, how it works, and explaining the benefits of running assessments
with smart contracts. This showed that the user interfaces and instructions were not
effective enough, and that public awareness on blockchain technologies and its benefits
was still quite primitive.
Overall, the demonstrator system has been a moderate success. All of the
participants (N = 4) have rated the demonstrator system positively. See Table 3 for the
response values for the first eight structured questions, where 1 is for Strongly disagree, 2
for Disagree, 3 for Neither agree nor disagree, 4 for Agree, and 5 for Strongly agree. All of
the participants said they would enrol into a platform like this in the future, praising its
transparency, trustworthiness, and user experience.

Increased trustworthiness
All of the participants (N = 4) agreed that the added level of transparency and provenance
could increase their trust in online education providers and credentials. Participants (N =
2) believes that the secure storage of detailed records that stay on the blockchain would
prevent future education history disputes.
Participants (N = 2) have noted that an institution could be more interested in using
an instance of the blockchain instead of participating in the global blockchain. A crowd-
sourced/ community-policing ratings feature was also suggested to further allow
reputation building on the system.
Versatile privacy controls
The access control feature in the learner application was received very positively.
Participants (N = 3) praised the access controls for learners and its previews. This is very
encouraging, showcasing that the access control possibilities on permissioned blockchains
can effectively preserve privacy.

Increased transparency of assessments

The participant reactions to the assessment features have been largely positive, the
“assessment contract” feature and the provision of marking criteria were praised:

• Most participants (N = 3) thought assessment feedbacks were enhanced by the

transparency of marking criteria;
• Participants (N = 3) said that the system could help resolve disagreements between
students and teachers, but not necessarily reduce the number of them;
• Participants (N = 2) liked the “assessment contract” interface, noting that it acts as a
reminder for the learners before submissions, which could on the other hand be a
source of stress.

One of the participants noted that the increase in transparency is only possible when
the quality of the information provided (eg. expectations, rubric) is high, which ultimately
depends on the course creators.
Participants (N=2) also wanted to see more forms of special requests logged on the
blockchain, such as assessment appeals and extenuating circumstances.

Well-supported personalisation
Our curriculum personalisation features were also highly praised, with all participants (N
= 4) praising the user interface as informative and easy-to-use.
The availability of support in the form of direct messaging was also unanimously
praised, with all participant agreeing that it would be a great channel for administrative
and pastoral support.

5. Conclusion
We designed and built a proof-of-concept blockchain e-learning platform that made use of
smart contracts to fulfil assessments and curricula and gathered feedback regarding its
features. We showcased the potential of blockchain technologies in increasing
transparency and trust in assessment processes and education credentials. We also
showed how flexible access control policies can be achieved on a permissioned blockchain
in the e-learning context.
Blockchain-based e-learning systems are already starting to materialise. In addition
to the projects outlined in Table 2, further examples include the real-world offerings:
Odem.IO (2018), BitDegree (2018) and the system at the University of Nicosia
(https://digitalcurrency.unic.ac.cy/). Unlike the commercial offerings at Odem and
BitDegree, we have released an openly available implementation that can be freely
studied. The system at the University of Nicosia stores hashes of certificates onto the
Bitcoin blockchain, thus implementing the approach described by Blockcerts. Unlike our
approach, their system does not use smart contracts and the blockchain is simply used as a
storage medium.

Value of peer execution and consensus

The main value-adding properties of blockchain technologies for e-Learning is the peer
execution and consensus process for assessments, and the distributed, immutable storage
of learner records.
By running transparent smart contracts on multiple blockchain peers, impartiality
of processes can be guaranteed, which contributes to the increased trustworthiness. This is
most valuable in assessments and credential generation. Consensus is not strictly
necessary for curriculum personalisation, but the distributed storage of those data
supports credential generation.
An increasing amount of research has also been focused on automating the marking
process. For example, Al-Yazeedi, Payne, and Cribbon (2012) have run an experiment on
using a programme to grade university project proposals and provide formative feedback.
The programme was able to give intensive feedback, with plagiarism and grammar
checks, and a semantic analysis on the quality of ideas. This shows that as marking
programmes become more mature, they could have a growing place in assisting teachers
and students. These technologies will make e-learning smart contracts extremely powerful.

Limitations

Human factors: Many potential improvements provided by our system are limited by
human actors. The quality of information and interactions are still dependant on
individual teachers and learners. Furthermore, Bryan and Clegg (2006) suggested that
having only the descriptions of learning outcomes, marking criteria and grade descriptors
in higher education is not enough, teachers should engage students in pre-assessment
activities that create a social construct of what those statements mean.

Diverse assessment form factors: Our design also took a very transactional view of
assessments, where a learner hands in a piece of work, which is then graded and the
results outputted. However, many real world assessment scenarios are more interactive,
such as real-time assessments, practical work, group projects, presentations, and
interviews. Institutions often depend on all of the above assessment types to test a full set
of learning outcomes and transferable skills.

Regulatory and governance barriers: Our proposed system can support the creation of a
global, open and flexible marketplace for curriculum personalisation. But the system
design does not offer solutions to how higher education regulations, finances, and other
issues related to institutional governance can be harmonised across the many different
education systems and jurisdictions in the world.

Immature technologies: Permissioned blockchain technologies are at an infancy stage and

not ready for prime time. Concerns are well-known about the scalability and security of
such networks, and their transaction speed and volume. For example, Vukolić (2015)
noted that the Byzantine fault tolerance consensus algorithm employed by permissioned
blockchains were only tested only up to 20+ peer nodes.
Public awareness: Public awareness of the functionalities and benefits of blockchain systems
and smart contracts seemed to stop at the belief that they are immutable and more secure.
Properties such as peer execution and consensus were not well understood. The user
interfaces of any consumer blockchain applications would have to do more to illustrate
these concepts through animations and detailed descriptions.

Future work
Our feedback study was limited by the number of participants and length of use. A future
study on a similar blockchain based e-learning platform deployed to a larger number of
participants for term time use would provide further validation of the proposed benefits.
We should further explore what smart contracts for other forms of assessments
would look like, such as peer assessments, self-assessments, and smart contracts for
group-based work. It would be highly valuable for smart contracts to be able to cover full
sets of higher education learning outcomes.
It would also be interesting to investigate the role of micropayments in e-learning
and assessments, which can be supported by a bespoke cryptocurrency, such as the one
proposed by Sharples and Domingue (2016) for building education reputation.

References
Alammary, A., Alhazmi, S., Almasri, M., & Gillani, S. (2019). Blockchain-based applications in education: A
systematic review. Applied Sciences, 9(12), 2400.
Allen, I. E., & Seaman, J. (2013). Changing course: Ten years of tracking online education in the united states. ERIC.
Al-Yazeedi, F., Payne, A., & Cribbon, T. (2012). Auto grading and providing formative feedback to students
on documents submitted electronically. In European conference on e-learning (p. 603).
Andersson, A., & Grönlund, ˚A. (2009). A conceptual framework for e-learning in developing countries: A
critical review of research challenges. The electronic Journal of information systems in developing Countries,
38(1), 1–16.
Bessonov, A.(2017, September 20). Five trends impacted by blockchain technology.
Retrieved from https://www.forbes.com/sites/forbestechcouncil/2017/09/20/five
-trends-impacted-by-blockchain-technology
BitDegree. (2018). Bitdegree whitepaper. Retrieved from https://www.bitdegree.org/ bitdegree-vision.pdf
(Accessed 29-09-18)
blockcerts.org. (2018). Faq - blockcerts : The open initiative for blockchain certificates. Retrieved from
https://www.blockcerts.org/guide/faq.html
Brown Jr, J. (1999). Assessment matters in higher education. McGraw-Hill Education (UK).
Bryan, C., & Clegg, K. (2006). Innovative assessment in higher education. Routledge.
Bülthoff, F., & Maleshkova, M. (2014). Restful or restless – current state of today’s top web apis. In V.
Presutti, E. Blomqvist, R. Troncy, H. Sack, I. Papadakis, & A. Tordai (Eds.), The semantic web: Eswc 2014
satellite events (pp. 64–74). Cham: Springer International Publishing.
Campbell, A. (2010). Digital forms of assessment: Assessing what counts, the performance.
Curriculum, technology & transformation for an unknown future. Proceedings ascilite Sydney, 2010.
Chen, G., Xu, B., Lu, M., & Chen, N.-S. (2018). Exploring blockchain technology and its potential applications
for education. Smart Learning Environments, 5(1), 1.
Christidis, K., & Devetsikiotis, M. (2016). Blockchains and smart contracts for the internet of things. IEEE
Access, 4, 2292-2303.
Condie, R., & Munro, B. (2007). The impact of ict in schools: Landscape review.
Dinh, T. T. A., Liu, R., Zhang, M., Chen, G., Ooi, B. C., & Wang, J. (2018). Untangling blockchain: A data
processing view of blockchain systems. IEEE Transactions on Knowledge and Data Engineering, 30(7), 1366–
1385.
Dron, J. (2007). Designing the undesignable: Social software and control. Educational Technology & Society,
10(3), 60–71.
Falkner, N., Vivian, R., Piper, D., & Falkner, K. (2014). Increasing the effectiveness of automated assessment
by increasing marking granularity and feedback units. In Proceedings of the 45th acm technical symposium on
computer science education (pp. 9–14).
García-Holgado, A., & García-Peñalvo, F. J. (2016). Architectural pattern to improve the definition and
implementation of elearning ecosystems. Science of Computer Programming, 129, 20–34.
Green, H., Facer, K., Rudd, T., Dillon, P., & Humphreys, P. (2005). Futurelab: Personalisation and digital
technologies.
Gros, B., & García-Peñalvo, F. J. (2016). Future trends in the design strategies and technological affordances
of e-learning. Learning, Design, and Technology: An International Compendium of Theory, Research, Practice,
and Policy, 1–23.
Gulhane, I. (2017). Create and execute blockchain smart contracts - ibm code. Retrieved 2018-01-03, from
https://developer.ibm.com/code/patterns/create-and
-execute-blockchain-smart-contracts/
Jacob, W. (2015). Interdisciplinary trends in higher education.
Lin, I.-C., & Liao, T.-C. (2017). A survey of blockchain security issues and challenges. IJ Network Security,
19(5), 653–659.
Odem.IO. (2018). Odem.io whitepaper. Retrieved from https://whitepaperdatabase.com/odem-ode-
whitepaper (Accessed 29-09-18)
Open University. (2018). Open blockchain. Retrieved from http://blockchain.open.ac.uk/
Poniszewska-Maranda, A., Goncalves, G., & Hemery, F. (2005). Representation of extended rbac model using
uml language. In International conference on current trends in theory and practice of computer science (pp. 413–
417).
Sadana, R., Agnihotri, M., & Stasko, J. (2018). Touching data: A discoverability-based evaluation of a
visualization interface for tablet computers. arXiv preprint arXiv:1806.06084.
Sharples, M., & Domingue, J. (2016). The blockchain and kudos: A distributed system for educational record,
reputation and reward. In K. Verbert, M. Sharples, & T. Klobuˇcar (Eds.), Adaptive and adaptable learning
(pp. 490–496). Cham: Springer International Publishing.
Sony Global Education. (2017). Sge education blockchain. Retrieved from https:// blockchain.sonyged.com/
Suhre, C. J., Jansen, E. P., & Torenbeek, M. (2013). Determinants of timely completion: the impact of
bachelor’s degree programme characteristics and student motivation on study progress. Higher Education
Research & Development, 32(3), 479–492.
Swan, M. (2015). Blockchain: Blueprint for a new economy. ” O’Reilly Media, Inc.”.
The Linux Foundation. (2018a). Introduction — hyperledger composer. Retrieved from
https://hyperledger.github.io/composer/introduction/introduction.html
The Linux Foundation. (2018b). Model compatibility — hyperledger composer.
Retrieved from https://hyperledger.github.io/composer/latest/reference/model
-compatibility
Underwood, S. (2016). Blockchain beyond bitcoin. Communications of the ACM, 59(11), 15–17.
Vukolić, M. (2015). The quest for scalable blockchain fabric: Proof-of-work vs. bft replication.
In International workshop on open problems in network security (pp. 112–125).
Walport, M. (2016). Distributed ledger technology: beyond block chain. UK Government
Office for Science.
Wüst, K., & Gervais, A. (2017). Do you need a blockchain? IACR Cryptology ePrint Archive, 2017, 375.
Xu, X., Pautasso, C., Zhu, L., Gramoli, V., Ponomarev, A., Tran, A. B., & Chen, S. (2016). The blockchain as a
software connector. In Software architecture (wicsa), 2016 13th working ieee/ifip conference on (pp. 182–191).
Yuan, E., & Tong, J. (2005). Attributed based access control (abac) for web services. In Web services, 2005. icws
2005. proceedings. 2005 ieee international conference on.

Appendix A. Access Control

The design of access control on the blockchain network was based on the Access Control
Language of Hyperledger Composer. The language allows for the creation of access
control rules that are conditional upon: the type of participant or asset, the use of a specific
transaction, and the values of properties of the participant or asset.
 This means the mode of access control for the blockchain is both role-based and
attribute-based (transaction and condition). Figure 13 is a generic representation of what
an access control rule deployed to the Hyperledger Fabric blockchain is composed of,
drawn based on the style proposed by Poniszewska-Maranda, Goncalves, and Hemery
(2005) for extended role-based access controls.

Attribute-based
Participant Roles Transactions
Users Conditions Permissions
eg. Teachers, Learners (optional)
(optional)

Operation(s) Object
eg. Assets, Participants

Figure 13. A flowchart representation of the Access Control model offered by Hyperledger
Composer
Most of the rules are a form of Mandatory Access Controls across the network,
enforced by the system and cannot be modified by users or client applications, where
access to objects is restricted based on fixed security attributes (Yuan & Tong, 2005). Unless
explicitly allowed by a defined access control rule, all operations are denied by default.
Some rules are more discretionary because the security-related attributes can be
changed by users. For example, a Learner will be able to set its own acLevels and
privilegedReaderIds fields to control what records related to the Learner that readers can read.
Integer values are stored in acLevels correlating to a permission permutation model
inspired by UNIX file permissions.
Table 4. The Reader access permutation model for Learner assets
0 1 2 3 4 5 6 7

Certificates (1) X X X X

Submissions (2) X X X X

Learner, Curriculums (4) X X X X

So, an acLevels value of [1, 3] would mean all Readers can read your Certificates,
while privileged Readers can read your Certificates and Submissions.
Table 5 and Table 6 list all of the access control rules designed for the blockchain of
this project.
 Table 5. The access control rules designed for our blockchain

Table 6. The access control rules designed for our blockchain (continued)
View publication stats