приложение, о котором вы говорите, - это просто клиентское приложение, которое обращается к бухгалтерской книге. Проблема здесь не в клиентском приложении, а в том, что вам нужна правильная политика одобрения, которая устанавливает, как что-либо попадает в бухгалтерскую книгу.
Представьте себе этот сценарий ...
у вас есть 2 организации, Org1 и Org2 , оба владеют одним пэром, P1 принадлежит Org1 , P2 принадлежит Org2 , и оба узла присоединяются к каналу, назовем его defaultchannel .
Вы развертываете и создаете экземпляр своего цепного кода и устанавливаете базовую политику одобрения, которая является 1-Of.
Каждая организация имеет клиентское приложение, работающее с собственным партнером. Когда Org1 отправляет транзакцию в бухгалтерскую книгу, ее достоверность подтверждается самой, а не второй организацией, потому что вашей политике требуется только одна для этого. По сути, в любой сети, где у вас есть более одной организации, вы действительно хотите получить надлежащую политику одобрения. 2-Of будет работать в нашем примере, так как любая транзакция должна быть проверена обеими организациями, и это обеспечивает большую целостность регистра.
В итоге, ваша фабричная сеть должна быть должным образом построена и защищена, особенно в производственной среде, и это позволяет защитить ее любыми клиентскими приложениями, которые имеют права на взаимодействие с ней. Защищенная сеть означает, что не имеет значения, как создается клиентское приложение и что оно пытается сделать, оно не сможет обойти такие механизмы, как механизмы одобрения.