5. PHYSICAL VIEW (1)
APPLICATION LAYER
Blockmaster is the brain of the whole system:
It deals the communication between users
Provided with a compensation module which takes
count of the debts of every user
Identity Manager support
DATA LAYER
Blockchain needed for data validation
Database used as storage system
6. PHYSICAL VIEW (2)
PRESENTATION LAYER
Each client is in possession of a certificate in order
to forward requests to the Blockmaster.
In addition, every user has the blockchain stored
locally.
CERTIFICATE ISSUER
The certificate issuer is a third party that Permus
recognizes as a trusted authority.
Every user that wants to join the system needs to
enroll by the CA and get a valid certificate.
8. TECHNICAL CHOICES
PERMUS SYSTEM
CRYPTOGRAPHY
In order to achieve a reasonable level of
security, commonly accepted cryptography
standards have to be used.
Throughout the proposed system three
cryptography
functions are used: hashing, encryption and
digital signature.
PUBLIC KEY
INFRASTRACTURE
Any subject expected to use the proposed
system needs to be positively identified.
The identity management method chosen
for the proposed system was a Public Key
Infrastructure with the use of
Digital Public Key Certificates and
Certificate Authorities
BLOCKCHAIN
Permissioned blockchains act as closed
ecosystems, where users are not freely able
to join the network.
Permissioned blockchains are preferred by
centralized organizations, which leverage
the power of the network for their own,
internal business operations.
9. USER IN PERMUS
In order to get access to the system, every user needs a personal certificate
CERTIFIED USER IN THE SYSTEM
Everyone belonging to the system is able to perform transfers, propose, accept
or refuse them.
ACCEPT AND PROPOSE
TRANSFERS
10. BLOCKMASTER
Central source of the system and manages different tasks which are necessary
in order to get a correct workflow of the application. Everything about a
transaction is done through the Blockmaster.
TRANSACTION HANDLER
Any request that comes from a client must be validated. It is only valid if it is
signed with a certificate from a subject who has previously been enrolled in
the blockchain.
IDENTITY MANAGER
Provide the user an update sending the missing blocks. At the same time, when
a new transaction is successfully computed by two subjects, both will get an
updated version of the current block where their transaction has been insert.
BRIDGE BETWEEN STORAGE AND
CLIENT
11. COMMUNICATION
Blockmaster works as a central source, a
hub.
Users send and ask for updates continously
to the system.
The Blockmaster makes sure that all the
requests for a transaction arrive correctly.
12. TRANSACTIONS
DIFFERENT CATEGORIES
It is possible to identify various types of transactions that are
necessary for the system to work properly.
SUBJECT IDENTITY: for the creation of a new user in Permus
TRANSFER: transactions meant for exchanges, further divided in:
SIGNED
CO - SIGNED
PUBLIC
PRIVATE
Signed and Co-Signed transactions depend of the type of transfer
a.
b.
c.
d.
13. TRANSFER
The two users agree on an exchange, the sender will do
the proposal and sign it. If the receiver agrees and
wants to accept the proposal, he will be signing the
transaction as well and it will be registered in the chain.
COMPENSATION
Core transaction present in Permus and the reason
why the whole system has been developed.
As the name reminds, with this type of
transfer, the sender is able to pay back old
transactions he had with the receiver.
1.
2.
19. CONCLUSION
WHAT HAS BEEN DONE
Touch with real hands cryptographic features
Cover different areas of software development
Use the blockchain in a different way than the
classic approach
FUTURE PLANS
Test the system on a real environment
Create a smartphone client supporting personal
certificates
Improve performance of the system
22. QUALITY OF THE SYSTEM
REQUEST HANDLER
Software is scalable itself, depending on the power of
the machine of the blockmaster it is possible to handle
more and more requests.
It is good to remind that Permus is designed for small
communities (~1000 people enrolled), which means one
single source can handle with no problems the requests.
"STRESSED" VALIDATION
For the validation efficiency, 100 000 transactions have
been added in the system:
Less than 10 minutes to validate the system once
logged in.
USUALLY TAKES LESS THAN A SECOND
