Определение сети Hyperledger Fabric / Hyperledger Composer для платформы регистрации курса - PullRequest
Новая
       8

Определение сети Hyperledger Fabric / Hyperledger Composer для платформы регистрации курса

0 голосов
/ 23 мая 2019

Я думаю о создании платформы регистрации курса блокчейна для «фитнес-центра». Я использовал Hyperledger Composer для просмотра примеров, но не нашел аналогичного примера для своей цели:

Каждый участник фитнес-центра должен иметь возможность - записаться на курс. - принять участие в нескольких курсах (отношение 1: n). - удалить его посещаемость - или передать свою регистрацию на курс другому члену фитнес-центра

Мой вопрос: Как бы вы создали умную модель проектирования в Hyperledger Composer с Fabric для моего варианта использования? Я сделал попытку здесь:

Моя главная проблема: Является ли конструкция отношений 1: n и n: n (для полного заполнения компонентов бизнес-сети: актив / участники / транзакции и события), что один участник имеет несколько курсов, а один курс может иметь несколько групп.

В качестве «Активы в модели Fabric / Composer» я предлагаю указать «Курс и группа» (?), Но как насчет отношения MatchingCourseToGroup и отношения «Участники в группе»? Где я должен это разместить? Будет ли это частью «Бизнес-логики», написанной в функциях?

В качестве «участников модели Fabric / Composer» я бы разместил участников.

Чтобы прояснить, что я хочу сделать: В SQL я создал бы эти таблицы для построения отношений (упрощенно для иллюстрации, * = PrimaryKey): 

(tbl: Course)
----------------------------------
CourseID* / Name
----------------------------------
001       ; Swim
002       ; Basic Training
003       ; Personal Training Class

(tbl: PersonalData)
----------------------------------
UserID*   / Name            
----------------------------------
1         ; Marc Miller
2         ; Tom Wood  
3         ; Mike Sun 

(tbl: MatchingCourseToGroup)
---------------------------------- 
GroupID*/ CourseID
----------------------------------
A       ;  001 (Group A belongs to the Swim Class)
B       ;  001 (Group B also belongs to the Swim Class)
C       ;  002 (Group C belongs to Basic Training)
D       ;  003 (and so on...) 
E       ;  003
F       ;  003

(tbl: ParticipantsInGroup)
---------------------------------- 
TicketID*/ UserID / CourseID
----------------------------------
01      ; 1 ; A
02      ; 1 ; B
03      ; 1 ; C
04      ; 2 ; A
05      ; 3 ; B
06      ; 3 ; C

Note:
Marc: takes part in 2 swim classes (Course with ID 001, received with primary key A) and (Course with ID 001, received with primary key B).
Other members can also take part in his Course.

Чтобы подойти к концу: я не совсем уверен, будет ли этот дизайн, как я это делал, работать в композиторе, возможно, у вас есть несколько хороших предложений для лучшего дизайна или подобного примера.

Потому что моей следующей проблемой будет создание хорошей реализации конфиденциальности, и поэтому, как я понял, я должен создать каналы для инкапсуляции членов с доступом для чтения, изменения возможностей или перемещения члена одной группы в другую и достижения права администратора.

(Идея состоит в том, что пользователи могут самостоятельно регистрировать их через планшет на входе).

Спасибо за вашу поддержку!

1 Ответ

0 голосов
/ 24 мая 2019

Если я правильно понимаю, что вам нужно сделать, вы можете попытаться смоделировать ваш файл .cto следующим образом: 

namespace org.test

participant Customer identified by customerId {
  o String customerId
  o String firstname
  o String lastname
  --> Course[] enrolledCourses
}

asset Course identified by courseId {
  o String courseId
  o String courseName
  o Integer participants
  o Integer maxParticipants default = 10
  o String status default = "OPEN"
  --> Customer[] participants 
}

transaction courseEnroll {
  --> Customer customer
  --> Course course
}

И в вашем файле логики js вы можете сначала выполнить транзакцию courseEnrollпроверка, если статус курса все еще "ОТКРЫТ".Добавьте клиента в массив participants в активе курса, обновите номер participants и проверьте, достигнут ли номер maxParticipants.В этом случае вы можете изменить статус на «Закрыть».

Относительно прав доступа вам необходимо определить некоторые правила в файле permissions.acl.Например, вы можете начать с этих двух правил: 

rule CustomerEnroll {
  description: "Customers can enroll for a course only with their account"
  participant(t): "org.test.Customer"
  operation: ALL
  resource(v): "org.test.courseEnroll"
  condition:  (t.getIdentifier() == v.customer.getIdentifier())
  action: ALLOW
}

rule CustomerSeeUpdateThemselvesOnly {
  description: "Customers can see and update their own record only"
  participant(t): "org.test.Customer"
  operation: READ, UPDATE
  resource(v): "org.test.Customer"
  condition: (t.getIdentifier() == v.getIdentifier())
  action: ALLOW
}
...