English | 中文

LTDRS（Lecture Ticket Distribution & Record System）

A lecture ticket distribution record system based on BigchainDB.

Introduction
Background
Development Purpose
Functions
Application Scenarios
Installation
Usage
Members
License

Introduction

Lecture Ticket Distribution & Record System based on BigchainDB mainly utilizes the main advantages of BigchainDB distributed database and traditional blockchain. Every lecture ticket issued in this system and its corresponding person can be recorded, ensuring the efficiency and fairness of the lecture ticket distribution process.

Background

BigchainDB takes advantage of the distributed database. It has blockchain attributes such as decentralization, invariance, autonomy, and database attributes such as high transaction rates, low latency, structured data indexing, and query. Compared with the traditional stand-alone database server, the BigchainDB database can better solve the efficiency problems of increasing, deleting, modifying, and querying caused by the scale increase; In contrast to the traditional blockchain, BigchainDB is truly "decentralized." In summary, the main special features of the database (version 2.0) include decentralization, Byzantine fault tolerance, immutability, autonomy, low latency, and structured data indexing and querying.
To study the implementation of these special features of BigchainDB, we must first understand the architecture of BigchainDB. In BigchainDB 2.0 version, each node in the BigchainDB network is deployed with a BigchainDB server and an independent MongoDB database. BigchainDB server is built based on MongoDB database. The data from the BigchainDB server is stored by MongoDB database, which makes BigchainDB have the characteristics of distributed database. The communication between nodes is determined by the Tendermint protocol, which runs on the BigchainDB server. It is through Tendermint that each node communicates and thus achieves consensus and the blockchain features of BigchainDB.
The following is a discussion of the implementation of these special functions based on the BigchainDB architecture:

Decentralization and Byzantine Fault Tolerance: BigchainDB is decentralized and Byzantine fault-tolerant. As Tendermint is Byzantine fault-tolerant, in the BigchainDB network, each node uses Tendermint to realize the networking and consensus of MongoDB of each node and then communicates on this basis. Therefore, the entire BigchainDB network is Byzantine fault-tolerant; that is, up to one-third of the nodes can fail in any way without breaking the consensus within the web, so there is no single point of failure in the BigchainDB network. In addition, because each node in the BigchainDB network has its own local MongoDB database, the whole BigchainDB network has no single owner, no single control point, and a single point of failure is eliminated, BigchainDB is decentralized.
Immutable: BigchainDB is immutable. Once data is stored in BigchainDB, it cannot be modified or deleted, or leave detectable traces. BigchainDB uses several strategies to achieve actual immutability. The most basic policy is not to provide an API to change or erase the stored data. Another approach is that each node has a complete copy of all the data in its MongoDB database. Another policy is that all transactions are cryptographically signed, and each data change is signed with a private key. Therefore, there must be a bit detectable trace left every time a modification or deletion is made.
Autonomy: BigchainDB, as a database with blockchain characteristics, also has the concept of asset user control of assets, and no one else can operate on assets that do not belong to them. In BigchainDB, only the asset owner can transfer the asset because the owner's private key must sign each asset transfer to achieve autonomy.
Low latency: BigchainDB has low latency for transaction processing. Since a consensus network based on Tendermint can quickly package a transaction into a newly committed block (usually in a few seconds), BigchainDB, which uses Tendermint for communication and consensus implementation, features low latency.
Structured Data Indexing and Querying: BigchainDB's queries and indexed data can have unique structures. Each node in the BigchainDB 2.0 network has its own local MongoDB database. It means that each node operator has the freedom to decide which interfaces to provide, how to use those interfaces, and what structure to index and query, based on the capabilities of the MongoDB database. In BigchainDB, the standard distributed database features are implemented by the MongoDB database owned by each node. In contrast, the implementation of blockchain features depends on the BigchainDB server and Tendermint.

Development Purpose

The management of lecture tickets on campus is chaotic, and there is a lack of effective certificates and vouchers. After transferring lecture tickets from the school department to the student department, the lack of management and tracking channels leads to the increase of disorder and unreliability in the giving and transfer of lecture tickets. As a result, before the comprehensive test and other examinations, the transaction of money and goods of lecture tickets is prevalent, which seriously violates the original intention of issuing lecture tickets. Therefore, we hope to develop an application system for schools, departments, and students and take advantage of the characteristics of BigchainDB so that departments can apply for lecture tickets according to their needs, distribute lecture tickets to students, and prevent students from trading lecture tickets to ensure the fairness of lecture ticket mechanism.
Therefore, we hope to develop a program to provide an immutable, secure and reliable system to ensure the fairness and effectiveness of lecture ticket distribution.

Functions

Login: Each user should log in with their public key and private key. If the public key and private key do not match, the user will not be given a login.
Search lecture tickets: Each student can check their lecture tickets. The school, as the administrator, should have the ability to check the lecture tickets of all students and designated students.
Transfer of lecture tickets: After creating the lecture tickets, the school should transfer the lecture tickets to each department. The department should also distribute the lecture tickets to designated students.
Create lecture tickets: the department will apply for lecture tickets from the school, provide the information of lecture tickets and the required quantity, and the school will have the ability to approve the application and create lecture tickets for the department.

Application Scenario

In this system, we have designed three different users: administrators, student departments, and students. Let's look at a simple example:

(1) Suppose that a new learning department is set up in the School of Software. The minister needs to register the department's name in the student department and obtain a unique pair of keys through which the minister can log in. After logging in successfully, the minister can fill in an application form and submit it to the school administrator for review. Such as:

Activity name: one to one help learning
Event time: 2020.6.28-2020.8.1
Venue: A1 Teaching Building, University Town Campus
Number of tickets: 300

The form information is unique in the chain, eliminating the possibility of creating invalid activities repeatedly. If approved, the department account will get the lecture ticket asset created by the administrator. After that, when some activities were carried out, the department staff could collect the student numbers of the students who participated in the activity and register them in the department account. Meanwhile, the department account also added additional conditions to the output: when these assets were to be transferred, the password signature of the department account was required, thus eliminating the possibility of lecture ticket trading. The lecture tickets have been transferred to the students.

(2) The administrator side will give the administrator a default account. After logging in, the administrator can view the activity declaration of the department side and choose not to reject the modification or pass the activity. The asset with the corresponding information is created and transferred to the related department through the activities. In addition, the administrator can also publish the activity information, and the activity information link can be displayed on the student side for students to click and view. In addition, the administrator also has the right to count the total number of lecture tickets finally. He can query the legal lecture tickets owned by all students or query the legal lecture tickets owned by a specific student through the student number.

(3) When entering the university, students can use their student ID to register and obtain their account (i.e., public-private key pair) on the registration page of the student side. Then students can log in to their account through the key pair. After logging in to the account, students can query the lecture tickets by inputting their student ID. Of course, the number of lecture tickets is the information that can be made public, and students can also query others' lecture ticket information by entering their student numbers. Still, we do not open the port to query all students' information.

Installation

We use Ubuntu 18.04's ISO running front and back end system, and use PyCharm under Flask framework to generate visual interface under BigchainDB, MongoDB, Terminate node.

Client: Use the browser to open the web page and follow the prompts to use.

Server:

Installation environment: Ubuntu18.04, Python version>=3.4.2
Install the BigchainDB database and the driver package BigchainDB-driver for Python, and program according to the driver. The details are as follows:

Install the BigchainDB in the line of professional guidepip install -U BigchainDB-driver(please install python3 & pip first)
use sudo apt install mongodb to install mongodb
Install flask using pip install flask
Install BigchainDB using pip3 install BigchainDB
BigchainDB-y Configure MongoDB
Download Tendermint and install it

(BigchainDB is developed based on Tendermint. Because it is prolonged to download the project from GitHub in China, the example can be downloaded by a third party and then unzip and installed.)
Start BigChainBD service:
Run the deployment server code