Introduction

Archeology offers a profound window into human history, revealing the complexities of past societies through the study of artifacts. These artifacts, ranging from monumental structures to everyday tools, provide invaluable insights into ancient lives and cultures1,2. Central to the modern archeologist’s toolkit is Open Source Software for Archeological Photogrammetry (OSSAP), which utilizes photogrammetry techniques to create detailed three-dimensional models of these artifacts from photographs. This technology has become indispensable for documenting and analyzing archeological findings. Yet, the field faces a significant challenge: the lack of a structured reward system for the volunteers who are crucial to the development and improvement of OSSAP3,4. Figure 1 displays the Archeological Data Types: Portable and Non-Portable Artifacts.

Fig. 1: Archeological Data Types.
figure 1

This figure illustrates the classification of archeological data into portable artifacts (e.g., tools, pottery) and non-portable artifacts (e.g., monuments, cave paintings), highlighting their relevance in digital documentation.

Full size image

Volunteers, driven by their passion for uncovering and preserving history, contribute significantly to the advancement of OSSAP. They engage in meticulous documentation and analysis, enabling a broader understanding of archeological sites and artifacts5,6. Despite their invaluable contributions, these volunteers often go unrewarded, facing challenges in receiving recognition and compensation for their efforts. This lack of a reward system undermines the motivation of contributors and potentially hinders the discovery and preservation of historical artifacts through OSSAP7,8. Figures 2 and 3 illustrate the Archeological Data Management: Taxonomy and Process Overview.

Fig. 2
figure 2

Taxonomy of archeological artifacts data.

Full size image
Fig. 3
figure 3

Process for collecting archeological artifacts data.

Full size image

The imperative for this study arises from the critical gap identified in the Open Source Software for Archeological Photogrammetry (OSSAP) ecosystem, where the absence of a structured reward system for volunteers significantly hampers the sustainability and efficacy of archeological endeavors. Despite the pivotal role of these volunteers in enriching the archeological repository with their meticulous documentation and analysis, their contributions are often undervalued and unrecognized9. This oversight not only demotivates the volunteer community but also jeopardizes the ongoing quest to uncover and preserve humanity’s historical narrative. Consequently, there is a pressing need to explore innovative mechanisms that can offer tangible recognition and rewards for their efforts.

This study introduces the Trust-Based Blockchain Model for Contribution (TBBMC), proposing a revolutionary approach to redefining the reward system within OSSAP. By leveraging blockchain technology, this model aims to instill a sense of trust, transparency, and fairness, thereby invigorating the volunteer base and ensuring the continued prosperity of archeological research and preservation. Figure 4 depicts the OSSAP Contributor Mechanism: Focusing on Enhancement Needs. This study explores the ethical responsibilities linked to archeological artifacts and proposes a novel, blockchain-based system named the TBBMC to address these challenges. TBBMC is designed to enhance transparency, trust, security, and traceability in OSSAP by utilizing a unique virtual currency for transactions and incentives, and integrating smart contracts to streamline operations such as currency exchange and fundraising initiatives10,11,12. This approach not only aims to fairly reward contributors but also maintains the integrity and authenticity of archeological contributions, fostering a more engaged and motivated community of volunteers. Figure 5 illustrates the Key Blockchain Features within the TBBMC framework: Revolutionizing Archeology.

Fig. 4
figure 4

OSSAP contributor mechanism: spotlight on enhancement needs.

Full size image
Fig. 5
figure 5

Key blockchain features in the TBBMC framework: transforming archeology.

Full size image

The structure of this paper is organized as follows: The ”Related Work” section reviews previous studies, focusing on their contributions to the field. The ”Proposed Methodology” section introduces the TBBMC framework, designed to enhance volunteer engagement in OSSAP. Following this, the ”Performance Evaluation” section presents an analysis of smart contracts on the Ethereum testnet, including how latency varies with increasing block numbers. Finally, the paper concludes with the ”Conclusion and Future Directions” section, summarizing key findings and outlining potential paths for future research.

Related work

Blockchain technology is increasingly recognized for its potential to incentivize and acknowledge contributions across various academic and practical sectors. This innovative approach enhances efficiency and transparency in recognizing significant achievements from diverse fields.

Guidi et al.13 explore the integration of blockchain technology with social media platforms, proposing a system where actions like posting, liking, and commenting are monetarily rewarded with digital currencies. This approach seeks to enhance user engagement by providing financial incentives for active participation on these platforms13.

Neelakandan et al.14 investigate the use of blockchain in social media to establish a transparent and verifiable system where user contributions are rewarded. Their study highlights the potential of blockchain in creating a more equitable and incentive-based social media ecosystem, where users receive compensation in the form of digital tokens or real money14.

Zheng et al.15 delve into the role of smart contracts in blockchain, emphasizing their ability to automatically recognize and verify user actions on digital platforms. This automation enhances trust and transparency, making the process of acknowledging contributions more efficient and less susceptible to manipulation15.

Azari16 presents a blockchain-based model for the real estate sector, proposing a system where interactions on social media platforms related to real estate can be rewarded. This model uses blockchain as a secure and immutable ledger to ensure the integrity of transactions and interactions, promoting more active participation16.

Guidi et al.17 further develop the concept of smart contracts in blockchain, focusing on their use in automating the recognition of user activities in online platforms. Their work emphasizes how such automation can improve the reliability and transparency of online engagement systems17.

Pasdar & Pranita18 explore the application of blockchain in enhancing the documentation and verification processes within various sectors. They suggest that smart contracts can significantly increase the level of trust and operational efficiency by providing a secure and transparent mechanism for recording and verifying transactions and interactions18.

Diamandis & Kelpvsiene19 study the immutable characteristic of blockchain, illustrating its potential in ensuring data integrity and reliability. They emphasize how blockchain can be used to reward users with digital tokens or cryptocurrency, based on meeting specific, predefined criteria, thus fostering a trustworthy and efficient reward system19.

The TBBMC framework presents a novel approach by integrating blockchain technology to transform incentive structures within the archeological field. Leveraging smart contracts, it meticulously records and compensates user interactions, including likes and comments, through digital tokens or financial incentives. This innovative system promotes fairness and transparency, establishing a novel benchmark for reward mechanisms that make each contribution valuable. Consequently, TBBMC marks a notable progression in applying blockchain to deliver concrete, ethical, and fair rewards for contributions in archeology.

Proposed methodology

This section unveils a novel framework TBBMC, designed to revolutionize archeological research through the integration of blockchain technology. At the heart of its design, the TBBMC framework significantly improves participation and reward mechanisms for contributors in OSSAP. The TBBMC framework marks a substantial leap in archeological research by integrating blockchain technology, emphasizing clarity, efficiency, and security in its participation process. It utilizes a blockchain to efficiently manage transactions, feedback, ratings, and secure payment transfers to digital wallets. This framework innovatively rewards participants for reaching milestones like achieving specific ratings or new subscriptions, promoting fairness and active involvement. Its strong security features, distributed ledger, and extensive database are tailored to meet the dynamic needs of archeological research. Overall, the TBBMC framework not only enhances project management in OSSAP but also fosters an inclusive and participatory environment for contributors, as detailed in Fig. 6.

Fig. 6
figure 6

Exploring the TBBMC ecosystem: redefining archeological incentives.

Full size image

The TBBMC framework utilizes blockchain technology to revolutionize archeological research, emphasizing security, transparency, and efficiency. It manages Contribution Rewards (CR), a virtual currency for the archeological community, through an Ethereum blockchain, handling transactions, feedback, and secure digital wallet payments. CR is earned by contributors for activities like excavation or data analysis and can be traded or used within the ecosystem. Smart contracts automate processes like currency conversion and fundraising, enhancing efficiency and transparency. The framework’s economic model addresses inflation and exchange rates to maintain CR’s stability. Contributions are tracked and verified via blockchain, with CR allocated accordingly. Investors can support projects through Initial Coin Offerings (ICOs), buying CR to fund research and create a market for the currency.

The Fig. 7 outlines the steps in a research process tailored for archeological photogrammetry, starting with the creation of a dataset and leading up to the publication of results using open-source software. Initially, there’s an ‘Analysis’ stage where researchers assess what data is needed. Following this, in the ‘Artifact Layer’, they create a dataset from collected photographic evidence. The ‘Contribution Layer’ involves enhancing this dataset with additional information or corrections. The ‘Attention Layer’ requires careful focus, likely on refining methods or data. At the ‘Interest Layer’, researchers engage with the data in a way that sparks further inquiry or reveals significant findings. The ‘Desire Layer’ represents the researchers’ aspirations to share their findings, setting the stage for the ‘Action Layer’, where they publish their work and release the software tools they used, contributing to the open-source community and the wider field of archeological research.

Fig. 7
figure 7

Archeological research process: from analysis to action.

Full size image

Contributors use CR for various purposes, including exchanging for fiat currency or accessing resources. All transactions are recorded on the blockchain, ensuring a transparent audit trail. The framework’s implementation requires collaboration with experts and continuous monitoring. Figure 8 represents the comprehensive TBBMC framework, detailing the workflow from contribution to reward. It includes steps like submitting artifacts, curating and integrating data, managing data iterations, verifying contributions, and rewarding through digital wallets. The framework also incorporates public engagement through social media and marketing, ensuring the visibility and accessibility of the project. It supports the gamification of archeological research, incentivizing participation and maintaining research integrity.

Fig. 8
figure 8

Proposed framework TBBMC: transparent blockchain-based mechanism for contributors.

Full size image

The proposed TBBMC framework features a layered architecture, as presented in Fig. 9, consisting of a user interface layer, an application layer, a business layer, a transparency layer, a decentralized layer, a distributed ledger layer, and a data layer. This architecture ensures a user-friendly interface for accessing and managing archeological datasets, with a focus on easy navigation. Crucially, it safeguards sensitive information by allowing only authorized users access, employing measures such as restrictions on user capabilities and data encryption.

Fig. 9
figure 9

TBBMC framework architecture: layered design for archeological data management.

Full size image

The framework aligns its security protocols with the organization’s overarching goals, through the establishment of policies and risk management in line with industry standards. A primary aim is to maintain full visibility of all system activities, underscored by vigilant monitoring and the maintenance of transparent records, particularly in response to any anomalies. The integration of blockchain technology is central to the framework, establishing an immutable record of transactions that bolsters data reliability and traceability. Moreover, the system distributes the responsibility for security data management across different components, enhancing the overall integrity and robustness of the security infrastructure. In addition, the framework functions as a secure repository for archeological data, regulating access and utilizing sophisticated encryption and storage techniques to guard against unauthorized access and breaches.

In Fig. 10, the initial ‘Analysis’ phase, researchers determine the necessary data. This progresses to the ‘Artifact Layer’, where a dataset is formed from gathered photographic evidence. In the ‘Contribution Layer’, this dataset is refined with extra details or corrections. The ‘Attention Layer’ demands meticulous attention, often to improve methods or data. During the ‘Interest Layer’, researchers delve into the data, sparking new inquiries or uncovering important insights. The ‘Desire Layer’ reflects the researchers’ goal to disseminate their discoveries, culminating in the ‘Action Layer’, where they publish their findings and release the tools they developed, thus contributing to the open-source community and enhancing archeological research.

Fig. 10
figure 10

Detailed archeological process flow: from data analysis to community contribution.

Full size image

Smart contracts for TBBMC

Figure 11 illustrates the TBBMC framework’s layered process workflow, integrating smart contracts. Initially, the algorithm establishes an ICO Contract contract, outlining several parameters such as the custom token’s name and symbol, the exchange rate for tokens in relation to Ether, the maximum allowable collection amount (cap) of Ether, the total Ether amassed up to that point (raisedAmount), an indicator (isICOActive) denoting the ongoing status of the ICO, and the designated wallet address for receiving the accumulated Ether.

Fig. 11
figure 11

Layered process workflow with smart contracts in the TBBMC framework.

Full size image

These parameters serve as the foundational elements that the program will utilize and modify throughout the ICO proceedings. Algorithm 1 describes the structure of an ICO Contract.

The Coin Reward Contract, as presented in Algorithm 2, a digital approach, is employed to monitor and allocate currencies. Utilizing a mapping system, the contract documents the coin holdings of participants and assigns specific privileges to the contract owner. Successful coin allocations are logged through a predefined event, while functionalities empower the owner to allocate coins and allow others to verify their balances. The contract restricts certain actions to the owner, ensuring both security and transparency. Essentially, it functions as an accessible ledger for the administration of digital coins and their rewards.

Algorithm 1

ICO Contract

  1. 1.

    Initialize ICOContract with custom token details (name, symbol), rate, cap, and wallet.

  2. 2.

    Declare state variables: token, rate, cap, raisedAmount, isICOActive, wallet.

  3. 3.

    Event: TokensPurchased - Log information about Ether purchase.

  4. 4.

    Constructor ICOContract.

  5. 5.

    5 Create a new ERC20 token.

  6. 6.

    Set rate, cap, wallet, and initialize isICOActive as true.

  7. 7.

    Modifier: onlyICOActive - Check if ICO is still active.

  8. 8.

    Receive function:

  9. 9.

    Only execute if ICO is active.

  10. 10.

    Ensure a non-zero amount of Ether is sent.

  11. 11.

    Calculate token amount using the rate.

  12. 12.

    Check if ICO cap won’t be exceeded.

  13. 13.

    Update raisedAmount and mint tokens to the buyer.

  14. 14.

    Emit TokensPurchased event.

  15. 15.

    Function endICO - Set isICOActive to false, ending the ICO.

  16. 16.

    Function withdrawFunds - Only executable by the contract owner (wallet).

  17. 17.

    Transfer entire Ether balance to the owner’s wallet.

  18. 18.

    Function withdrawTokens - Only executable by the contract owner (wallet).

  19. 19.

    Transfer all remaining tokens to the owner’s wallet.

  20. 20.

    Modifier onlyOwner - Check if the caller is the owner of the contract.

The ”CRConverter” smart contract initializes the CR token and conversion rate variables, configuring them in the constructor during contract deployment as described in Algorithm 3. The ”convertToFIAT” function facilitates the conversion of a specified CR amount to fiat currency, ensuring the caller possesses a sufficient CR balance. The fiat amount is calculated using the predetermined conversion rate. The contract’s primary objective is to trigger a ”Conversion” event, logging details about the contributor, including their address, CR amount, and the corresponding fiat amount. This algorithm lays the groundwork for a blockchain-based system, aiming to enhance the speed and transparency of the conversion process, providing a means for participants involved in archeological artifacts to engage.

The ”CR Market Contract” in algorithm 4 initiates a smart contract facilitating the purchase and sale of CR. The contract is established, and the variable crToken, representing CR, is declared. Through the constructor, crToken is instantiated by creating an instance of the CRToken contract. The buyCR function enables users to acquire CR with Ether, ensuring adequate funds and emitting a CRPurchased event upon success. Similarly, the sellCR function empowers users to sell CR, receiving Ether and triggering a CRSold event. This algorithm streamlines transactions in the ancient artifact market, laying the groundwork for an efficient and transparent blockchain-based CR market.

Algorithm 2

Coin reward contract

  1. 1.

    Initialize smart contract named CoinRewardContract.

  2. 2.

    Create mapping balances to keep track of balances for each address.

  3. 3.

    Declare variable owner to store the address of the contract owner.

  4. 4.

    Define event CoinsRewarded to log successful reward transactions.

  5. 5.

    Constructor CoinRewardContract.

  6. 6.

    Set owner to the address of the message sender.

  7. 7.

    Function rewardCoins(recipient (address), amount (uint256)).

  8. 8.

    Check if the caller is the owner of the contract.

  9. 9.

    Update the balance of recipient by adding the specified amount.

  10. 10.

    Emit the CoinsRewarded event to log the reward transaction.

  11. 11.

    Function checkBalance(account (address)) → uint256.

  12. 12.

    Return the balance associated with the specified account.

  13. 13.

    Modifier onlyOwner.

  14. 14.

    Check if the caller is the owner of the contract.

  15. 15.

    Continue with the execution of the function if the condition is met.

Algorithm 3

CR to Fiat Conversion Smart Contract

  1. 1.

    Initialize smart contract named CRConverter.

  2. 2.

    Declare variable crToken of type CRToken to represent the CR token.

  3. 3.

    Declare variable conversionRate of type uint256 to store the conversion rate.

  4. 4.

    Constructor CRConverter(address crToken, uint256 conversionRate).

  5. 5.

    Set crToken to a new instance of CRToken at address crToken.

  6. 6.

    Set conversionRate to conversionRate.

  7. 7.

    Function convertToFIAT(uint256 crAmount).

  8. 8.

    require(crToken.balanceOf(msg.sender) >= crAmount, ”Insufficient CR balance”).

  9. 9.

    Calculate fiatAmount by multiplying crAmount with conversionRate.

  10. 10.

    // Implement your fiat transfer logic here.

  11. 11.

    // For simplicity, emit an event with the conversion details.

  12. 12.

    emit Conversion(msg.sender, crAmount, fiatAmount).

The ”CR Token Contract” in algorithm 5 details a Solidity smart contract facilitating CR transfers. Initialization involves the creation of a balance-tracking mapping and the declaration of an owner variable. Successful transfers trigger the recording of events through ”CRTransferred.” The constructor links the message sender’s address to the owner variable. Users execute CR transfers using the ”transferCR” function, which mandates a valid recipient, a positive amount, and an adequate balance. Upon completion, the function emits the ”CRTransferred” event. The approach incorporates ” onlyOwner” to restrict specific functions to the contract owner and ”checkBalance” for querying CR balances. This concise description encapsulates the CR transfer process within a secure and transparent blockchain-based framework

Impementations

This section explains how we set up the system to safely share money on the Binance local chain. We’ve made sure to use the security features of blockchain technology in this process. We also created our own methods, inspired by the ”Alternateth” idea. For example, to tackle worries about using too much energy, we made a Proof of Work (PoW) method that can be adjusted for difficulty. We’re using an HP ProBook Core i5 10th generation to check which chain is the longest and has the most nodes. If a chain has the most nodes, it gets the green light from the network and takes over all nodes in the Binance local chain.

Algorithm 4

CR Market Contract.

  1. 1.

    Initialize smart contract named CRMarketContract.

  2. 2.

    Declare variable crToken of type CRToken to represent the CR token.

  3. 3.

    Constructor CRMarketContract(address crToken).

  4. 4.

    Set crToken to a new instance of CRToken at address crToken.

  5. 5.

    Function buyCR(uint256 amount) payable:

  6. 6.

    require(msg.value > 0, ”Insufficient Ether sent”).

  7. 7.

    require(crToken.balanceOf(address(this)) >= amount, ”Insufficient CR available for sale”).

  8. 8.

    cost = amount * 1 ether▷ Assuming 1 ETH per CR for simplicity.

  9. 9.

    require(msg.value >= cost, ”Not enough Ether sent for the requested CR amount”).

  10. 10.

    crToken.transfer(msg.sender, amount).

  11. 11.

    payable(owner()).transfer(msg.value).

  12. 12.

    Function sellCR(uint256 amount):

  13. 13.

    require(crToken.balanceOf(msg.sender) >= amount, ”Insufficient CR balance for sale”).

  14. 14.

    revenue = amount * 1 ether▷ Assuming 1 ETH per CR for simplicity.

  15. 15.

    crToken.transferFrom(msg.sender, address(this), amount).

  16. 16.

    payable(msg.sender).transfer(revenue).

  17. 17.

    emit CRSold(msg.sender, amount, revenue).

Algorithm 5

CR Taken Contract.

  1. 1.

    Initialize smart contract named CRTokenContract.

  2. 2.

    Create mapping balances to keep track of balances for each address.

  3. 3.

    Declare variable owner to store the address of the contract owne.

  4. 4.

    Define event CRTransferred to log successful CR transfer transactions.

  5. 5.

    Constructor CRTokenContract.

  6. 6.

    Set owner to the address of the message sender.

  7. 7.

    Function transferCR(to (address), amount (uint256)).

  8. 8.

    Check if the to address is valid.

  9. 9.

    Check if the amount is greater than 0.

  10. 10.

    Check if the sender has a sufficient CR balance.

  11. 11.

    Transfer amount of CR from the sender to to.

  12. 12.

    Emit the CRTransferred event to log the CR transfer transaction.

  13. 13.

    Function checkBalance(account (address)) → uint256.

  14. 14.

    Return the balance associated with the specified account.

  15. 15.

    Modifier onlyOwner.

  16. 16.

    Check if the caller is the owner of the contract.

  17. 17.

    Continue with the execution of the function if the condition is met.

Performance

In this segment of the research, we scrutinized the functionality and efficacy of our custom-built framework, TBBMC, in scenarios drawn from real-world applications.

Assessment of performance

The development of the TBBMC blockchain network was executed using Spyder IDE Version 4.2.5, with an emphasis on Python programming. This phase was dedicated to evaluating the system’s performance. Additionally, the Postman tool, Version 8.5.1, played a crucial role in facilitating interactions with APIs. For the purpose of graphically representing data concerning chain size and latency, the matplotlib library in Python was utilized.

Evaluation criteria

The evaluation of the TBBMC framework was based on two primary metrics: block size assessment and latency measurement, elaborated as follows:

Block size assessment

The block size is indicative of the volume of data contained within a block, encompassing transaction data in the chain. This study focused on examining the block size to determine the average increase in the size of files/blockchain.

Latency

Latency refers to the delay encountered when one component of a system is awaiting a response from another. In the blockchain context, it signifies the time elapsed from submitting a transaction to the network to receiving the initial confirmation of acceptance.

Performance evaluation

This section delves into the empirical evaluation of TBBMC in real-case scenarios, particularly focusing on performance aspects. The TBBMC blockchain network was implemented to facilitate real-time data transfer and transaction processing. The setup of HTTP requests, both ‘GET’ and ‘POST’, was achieved using the Postman tool to interface with APIs. Six distinct functions were employed as use cases to validate the efficacy of our proposed framework:

  1. 1.

    getCompleteChain.

  2. 2.

    connectNewNode.

  3. 3.

    mineBlock.

  4. 4.

    addTransaction.

  5. 5.

    isChainValid.

  6. 6.

    replaceChain.

In Postman, a random transaction was repeatedly sent through HTTP requests 700 times. The blockchain size, ranging from 0.448 KB to 500 KB, expanded as new blocks containing transactions were added. Figure 13 illustrates that an increase in the number of blocks leads to a corresponding increase in the blockchain size, with an average size increment of 248 KB. It also highlights that blocks with a high transaction count significantly impact the file sizes, particularly noticeable between 100 and 110 blocks and 590 and 600 blocks, following a linear trend. The number of transactions per block wasn’t predetermined during the development of this specific use case, leading to a marginal increase in the size of newly mined blocks. Figure 12 demonstrates that as the number of blocks increases, the file size for TBBMC also increases.

Fig. 12
figure 12

The increase in blocks increases the file size for TBBMC.

Full size image

The study involved assessing all current chains in the TBBMC blockchain network. Chains were replaced with the longest chain available at a given timestamp, adhering to all necessary steps for processing the HTTP request. This procedure allowed for an analysis of the time required to execute the ‘ replacechain’ request via HTTP, providing insights into the latency involved in obtaining the current longest chain.

Figure 13 reveals variable delays in executing the HTTP requests. These fluctuations are attributed to the decentralized nature of the blockchain, which involves multiple nodes and lacks a central controlling system. The performance of the TBBMC blockchain network’s multiple servers varies based on individual system response times to numerous requests, machine speed, and internet bandwidth. These factors collectively contribute to the latency experienced in executing HTTP requests across different servers.

Fig. 13
figure 13

Time spent in getting the longest chain in TBBMC.

Full size image

Discussion

This segment methodically presents the experimental findings of our scalable, secure, and transparent TBBMC framework, demonstrating its efficiency in performance. The framework proves beneficial in the successful execution of archeological projects within AIDA (Archeological Investigation and Development Authority), offering a collaborative and distributed platform for its contributors. TBBMC effectively tackles key challenges such as trust, traceability, security, transparency, communication, and coordination. These challenges are addressed through the utilization of blockchain technology, leveraging its decentralized structure, consensus mechanisms, distributed data storage, and robust security features. Absence of these essential elements in distributed systems can lead to project delays, financial disputes, cancellation of deals, dissatisfaction among museum governing bodies, and a lack of trust.

Our performance evaluation shows that the integration of blockchain technology in TBBMC is crucial in overcoming these obstacles for the thriving execution of archeological projects. TBBMC incorporates a private Binance blockchain and presents users with seven distinct layers, each providing a virtual wall to guide them through the archeological project lifecycle. The integration of blockchain in TBBMC offers numerous advantages:

Its decentralized nature aligns well with the needs of AIDA. A user-friendly interface is provided for the seven virtual walls via DApps, facilitating effective global communication and collaboration. The consensus mechanism in blockchain enhances coordination within AIDA. The Binance blockchain in TBBMC enables automatic acceptance testing, verifies payment requirements for contributors, and distributes payments to the digital wallets of the archeological team through smart contracts. Blockchain technology equips distributed users with digital wallets and cryptocurrency for transactions, like Ethereum (Ether). The satisfaction of Museum Governing Bodies is assured as blockchain promotes transparency. Blockchain ensures secure payment transactions, enhancing overall security. Additionally, TBBMC’s use of a private Binance blockchain limits node participation, reducing the risk of 51% attacks.

Blockchain technology proves effective in monitoring the progress of dispersed agile teams by documenting their performance on the blockchain. Key findings demonstrate that implementing blockchain technology within TBBMC effectively resolves issues related to trust, security, transparency, traceability, communication, and coordination. This aspect of blockchain helps to prevent project deal cancellations, financial disputes between clients and developers, client dissatisfaction, and delays or failures in projects. Additionally, employing IPFS for off-chain secondary storage significantly lessens the data burden on the blockchain, thereby enhancing the speed of TBBMC transactions.

Our research shows that blockchain technology is a pivotal component of this study, significantly improving the software development process in AIDA. Previous research in this area has not introduced a framework that is as efficient, transparent, secure, and scalable using blockchain technology, particularly for addressing the key issues of trust, traceability, security, and transparency in AIDA. These earlier studies, lacking the integration of blockchain, only addressed coordination and communication challenges in AIDA. Therefore, our TBBMC framework surpasses previous models and research in AIDA by incorporating blockchain technology.

However, there are limitations to using the Binance blockchain within the TBBMC framework, notably the high energy consumption required for block mining. Also, modifying data once it’s stored on the blockchain is challenging. Overall, the performance results indicate that blockchain technology holds tremendous potential to revolutionize the future of AIDA and can bring significant changes to global archeological governing bodies.

System setup

Our system setup is based on the Alternateth concept, intricately designed to incorporate various levels of complexity for CRs. Implementing a proof-of-work approach, our adaptable blockchain comprises a genesis block. To mine a block, the SHA256 hexadecimal number must commence with four leading zeros. If this condition is not met, the proof value undergoes iterative adjustments until fulfillment. CRs blockchain validation ensures each block has the correct proof-of-work, and the current block’s hash aligns with the prior block’s hash. Consensus, vital for uniformity among connected nodes, is achieved through network establishment, determining maximum chain lengths for each node, and selecting the longest chain as the consensus. Initially stored independently, transactions seamlessly integrate into the blockchain when miners discover a new block, enhancing the CRs system’s efficiency.

To expedite CRs, we manage a dedicated transaction pool for early transactions, guaranteeing their swift processing before integration into the blockchain. Completing a transaction requires three vital details: the recipient’s address, the sender’s address, and the transfer amount. Our blockchain technology relies on a consensus process to ensure uniformity among interconnected nodes with identical blockchain copies. Strengthening system integrity involves establishing maximum chain lengths, selecting the longest chain as the consensus, and initiating the network. Transactions seamlessly become part of the blockchain when miners successfully generate a new block containing specific CRs transfers between cryptocurrency wallets. This streamlined process enhances the overall efficiency of our blockchain system.

Publish smart contract

The Remix compiler produces bytecode that is used to launch a smart contract on the Ethereum Testnet. The deployment procedure requires the use of this bytecode. A private key is needed to sign a transaction on the Ethereum Testnet, and the gas limit for transaction signing is a set quantity of Ethereum (testnet Ether). On the Ethereum Testnet blockchain, the smart contract’s deployment is documented as a transaction.

Dapps for connecting to smart contract

To interact with our smart contracts, obtaining the ABI specific to each contract and the corresponding Contract Address is essential. These details are generated during the deployment of the CR or ICO contract on the Ethereum Testnet. This combination enables access to distinct functionalities within each contract, encompassing CRs and ICO operations. Each transaction executed by these contracts results in the creation of a record in a blockchain block, encompassing key information such as block hash, senderaddress, transaction data, and Gas used.

Possible vulnerabilities for smart contracts

The smart contracts governing CR, ICO, and the preservation of archeological artifacts integrate specific values and regulations. Even a minor coding error in these contracts can lead to significant issues, including financial losses and privacy infringements. Given the sensitive nature of these transactions, ensuring robust security measures is paramount. The possibility of malicious nodes within the network exploiting vulnerabilities in smart contracts for personal gain underscores the importance of adhering to stringent security standards. To avert any compromise in privacy, financial integrity, or artifact preservation, these smart contracts must meticulously address potential bugs and vulnerabilities.

Timestamp dependence vulnerability

The Timestamp Dependence Vulnerability impacts both CR and ICO smart contracts on the Ethereum. Altering timestamps during transactions poses a threat to operations tied to them, like the distribution of rewards. This underscores the importance of securing processes reliant on timestamps and implementing robust defenses to prevent such exploits, ensuring the integrity of critical operations.

Transaction ordering dependencies vulnerability

A vulnerability associated with Transaction Ordering Dependencies impacts both CR smart contracts on the Ethereum and the ICO. In both contracts, there’s a potential vulnerability wherein the order of transactions can be influenced by miners selecting those with higher fees. Donors employing high transaction fees to expedite processing might introduce dependencies that miners could exploit, jeopardizing the secure and equitable execution of these transactions.

Mishandled exceptions vulnerability

The mismanaged exclusivity vulnerability is a common issue for both CR smart contracts on the Ethereum and ICO contracts. Due to dependencies on multiple processes, including intricate transactions and third-party exchanges, it becomes crucial to handle exceptions properly. Robust exception-handling procedures are imperative, as mishandling exceptions could potentially expose these smart contracts to risks.

Callstack depth vulnerability

The Callstack Depth Vulnerability impacts both CR and ICO smart contracts on the Ethereum. Each time one smart contract calls another, the call stack expands, and surpassing BSC’s call stack limit may result in an exception. This underscores the importance of meticulous control over call stack depth to prevent potential exploits and ensure the secure functioning of these smart contracts.

Re-entrancy vulnerability

The Re-Entrancy Vulnerability impacts both CR smart contracts and ICO contracts on the Ethereum. It opens up the possibility for attackers to exploit dependent smart contract calls that wait for prior calls to complete. Utilizing the fall-back feature, attackers could initiate repeated calls, potentially leading to multiple transactions and posing a risk to the remaining contributions or incentives. Mitigating this vulnerability is crucial to uphold the security and integrity of these smart contracts on the Ethereum.

Performance evaluation

We gauge the efficacy of our proposed methodology in practical scenarios by focusing on the dynamics of data transfers and transactions on the Ethereum test network for artifacts. Employing use cases like mine lock and replace hain functions and utilizing Postman for API interactions, we replicate real transactions 500 times with random data. The size of the blockchain steadily grows from 0.446 KB to 200 KB across 500 blocks, demonstrating an essentially linear progression (Fig. 12). The average size increment of 94.9 KB is marked by noticeable spikes, correlated with higher transaction volumes in recently mined blocks. This underscores the model’s adept handling of evolving data loads.

Supplementing the performance assessment, we delve into latency analysis, specifically examining the time taken for HTTP replace chain requests. Figure 13 encapsulates the average latency results gathered from ten experiments, underscoring the decentralized nature of blockchain technology. Illustrated in Fig. 13, the sporadic variations in request execution times underscore the intricacies of latency evaluation. These fluctuations are attributed to the decentralized operation of nodes, each functioning independently with distinct system capacities and response times, contributing to nuanced execution delays within the network.

Understanding the intricacies of performance is paramount, and this evaluation underscores the model’s robustness within the decentralized BSC environment. In a decentralized network, random delays are inevitable, showcasing the diverse operational capabilities of individual nodes. A comparative analysis between existing related work and the proposed TBBMC framework, evaluated across key features such as Blockchain, Rewards, Documentation, Online Engagement, Social Media, Automation, and applicability to Archaeology had been presented in Table 1.

Table 1 Comparative analysis: related work versus TBBMC framework
Full size table

Conclusion and future directions

The research underscores the growing global recognition of ethical responsibilities concerning archeological artifacts, resulting in increased funding through CR. However, motivating contributors faces challenges due to transparency concerns in artifact gathering methods. In response, the study introduces a blockchain-based system prioritizing auditability, security, transparency, and efficiency in handling archeological relics. This platform utilizes cryptocurrency wallets, an economic model, ICOs, and a unique approach with CR as virtual currency. The integration of smart contracts streamlines essential processes, providing a robust foundation to address transparency issues and foster trust between contributors and organizations.

Further investigations should assess the practical effectiveness of the blockchain-driven system in archeology, evaluating its ability to improve transparency, attract participants, and ensure secure transactions. Understanding the factors that drive users to adopt and trust the system is crucial for its credibility and progress. Given the use of cryptocurrency, it’s important to examine evolving regulations for compliance and widespread adoption. Evaluating the system’s scalability and sustainability, resolving issues, and finding remedies are essential for its long-term success. Encouraging international collaboration among researchers, technology specialists, and archeological organizations can enhance the system’s functionality, standardize its use, and ensure ethical artifact management. Addressing these issues will propel the advancement of blockchain technology in archeology, fostering inclusion, security, and transparency.