Interoperability Between Smart Contracts and the HCS

[scalemaildev]

---

hip: <HIP number (this is determined by the HIP editor)>
title: Interoperability Between Smart Contracts and the HCS
author: John Conway (@scalemaildev)
working-group: a list of the technical and business stakeholders' name(s) and/or username(s), or name(s) and email(s).
type: Standards Track
category: Core
needs-council-approval: <Yes | No>
status: Draft
created: 05-17-2022
discussions-to:
updated:
requires: <HIP number(s)>
replaces: <HIP number(s)>
superseded-by: <HIP number(s)>

Abstract

Enable the reading, writing, and creation of HCS topics via smart contracts.

Motivation

Interoperability between the HCS and Hedera's smart contracts would enable Solidity developers to leverage HCS-stored data.

Rationale

Enabling smart contracts to read/update/create HCS topics would enable record-based NFT minting. Currently, if we want to restrict the ability to mint an NFT based on a meta record, it has to be done in a centralized fashion. The server would first read the user's record HCS topic, check if the record has valid credit, mint the appropriate NFT, send that NFT to the user's wallet, and then update their HCS topic. However, this could all be done through a smart contract (without the need for a server) if smart contracts had CRUD access to HCS topics.

User stories

As a developer, I want to be able to read HCS topics from my smart contracts.

As a developer, I want to be able to send HCS topic messages from my smart contracts (needs a payer account).

As a developer, I want to be able to create HCS topics from my smart contracts (needs a payer account).

Specification

The technical specification should describe the syntax and semantics of any new features. The specification should be detailed enough to allow competing, interoperable implementations for at least the current Hedera ecosystem.

Backwards Compatibility

All HIPs that introduce backward incompatibilities must include a section describing these incompatibilities and their severity. The HIP must explain how the author proposes to deal with these incompatibilities. HIP submissions without a sufficient backward compatibility treatise may be rejected outright.

Security Implications

If there are security concerns in relation to the HIP, those concerns should be explicitly addressed to make sure reviewers of the HIP are aware of them.

How to Teach This

For a HIP that adds new functionality or changes interface behaviors, it is helpful to include a section on how to teach users, new and experienced, how to apply the HIP to their work.

Reference Implementation

The reference implementation must be complete before any HIP is given the status of “Final”. The final implementation must include test code and documentation.

Rejected Ideas

Throughout the discussion of a HIP, various ideas will be proposed which are not accepted. Those rejected ideas should be recorded along with the reasoning as to why they were rejected. This both helps record the thought process behind the final version of the HIP as well as preventing people from bringing up the same rejected idea again in subsequent discussions.

In a way, this section can be thought of as a breakout section of the Rationale section that focuses specifically on why certain ideas were not ultimately pursued.

Open Issues

While a HIP is in draft, ideas can come up which warrant further discussion. Those ideas should be recorded so people know that they are being thought about but do not have a concrete resolution. This helps make sure all issues required for the HIP to be ready for consideration are complete and reduces people duplicating prior discussions.

References

https://hedera.com/blog/use-cases-for-hcs-based-records-in-play-to-earn-nft-gaming

Copyright/license

This document is licensed under the Apache License, Version 2.0 -- see LICENSE or (https://www.apache.org/licenses/LICENSE-2.0)

[walter-hernandez]

I like the idea @scalemaildev. I want to expand to add more detail to the HIP draft.

Abstract

The general purpose of this HIP is to facilitate Smart Contract to interact with topics by allowing contracts to create them and write, read, update the messages in the topic.

Rationale

By enabling topics to interact with smart contracts, these topics can then enable the creation of Oracles. For example, an Oracle smart contract can be listening to new messages from a private or public topic from where some data is passed to it from outside Hedera, like prices of crypto-assets.

Other smart contracts in Hedera can now interact with this Oracle Smart Contract to get data from outside Hedera to use in their logic.

Specification

An approach to allow Smart Contracts to interact with topics would be to have pre-compiled HCS smart contracts following the same approach as the HTS pre-compiled contracts

Security Implications

The signing of transactions from within the Smart Contract to interact with the topic. The main concern is with the need of having to store private keys in the state to allow the signing of the transactions with the topic. So, some possible options to solve for these are:

• Look into how it would be possible to, for example, allow from Hedera's SDKs to give different types of permissions to deployed smart contract to interact with a certain topic created through Hedera's SDKs
• Follow the same approach from the HTS pre-compiled contracts to sign transactions and interact with topics

[scalemaildev]

• Follow the same approach from the HTS pre-compiled contracts to sign transactions and interact with topics

Can you elaborate/summarize this approach for the PR? See recent comments: #478

[walter-hernandez]

hello @scalemaildev! I added the comment with more detail to #478

[scalemaildev]

PR updated with Hernandez additions.