Content uploaded by George Darzanos
Author content
All content in this area was uploaded by George Darzanos on Mar 04, 2024
Content may be subject to copyright.
Efficient and Budget-Balanced Decentralized
Management of Federated Cloud
and Edge Providers
George Darzanos∗, Thanasis G. Papaioannou∗† and George D. Stamoulis∗
∗Athens University of Economics and Business (AUEB), Greece
†National and Kapodistrian University of Athens (NKUA), Greece
{ntarzanos, pathan, gstamoul}@aueb.gr
Abstract—Federations of Infrastructure Service Providers (Inf-
SPs) have emerged as an effective practice to cater for demanding
applications in cloud- and edge-computing environments, by
overcoming the limitations of each such provider (in terms of
available resources, geographic coverage etc.). In this paper, we
develop innovative mechanisms and policies for the decentralized
management of InfSP federations, considering the needs both for
resource allocation meeting service composition requirements,
and for performing a fair and efficient distribution of profits.
Resource allocation is performed by means of a greedy algorithm
that includes an opportunistic and an adjustment phase. To
determine the payments of participating InfSPs, we introduce an
innovative sealed-bid reverse auction that combines VCG and
first-price auction mechanisms. This hybrid mechanism, coupled
with a sophisticated federation wallet management mechanism,
serves as a revenue sink for the federation. Notably, our approach
exhibits several nice properties, including efficiency, long-term
budget balance, truthfulness and individual rationality. Further-
more, we present how our solution can be implemented in a
decentralized, privacy-preserving and trustworthy manner over
a blockchain, achieving bid privacy, non-repudiation and public
verifiability. Our approach is evaluated by means of extensive
experiments, the results of which reveal that resource allocation
is either optimal or very close thereto, while individual InfSP
profits as well as total federation profits are maximized. The
results underscore the inadequacy of relying solely on the VCG
mechanism for budget balance, justifying the necessity of our
sophisticated hybrid solution.
I. INTRODUCTION
Cloud computing offers ubiquitous and convenient access to
virtualized infrastructure and service, allowing for on-demand
scalability and flexibility. As cloud computing continues to
evolve, we are witnessing a convergence of cloud with next-
generation networks, namely 5G and 6G, expected to revolu-
tionize applications in various vertical sectors, such as auto-
motive, media, smart cities, etc. These new era applications
offered by Vertical Service Providers (VSPs), require near-
real-time data processing, making edge computing an essential
element for their realization. Edge computing is a paradigm
that brings computation and data storage closer to the location
it is needed, reducing latency and increasing efficiency.
Hence, infrastructure and service offerings that combine
computational, storage, and network resources from central
Cloud Providers, Mobile Network Operators, Edge Cloud
Providers, and even Internet of Things (IoT) platforms are
necessary to support such demanding applications. We en-
compass all these stakeholders under the ”umbrella” term
Infrastructure Service Provider (InfSP). Given the coverage
limitations of different InfSPs and the diversity of resources
and services required to provide complete solutions to VSPs,
the formation of federations of InfSPs has emerged as a
practice to effectively meet relevant requirements.
In an InfSP federation, different InfSPs come together and
collectively create a large-scale virtualized infrastructure to
jointly offer services to customer VSPs. Through their par-
ticipation in such federations, InfSPs can generate additional
revenues because they can contribute to the provisioning of
solutions that they could not support on their own. The concept
of federation is primarily observed in the cloud computing
domain but also appears in IoT and network domains. Nev-
ertheless, the formation of federations poses several technical
and, most importantly, non-technical challenges.
Federation Challenges. On the technical side, the main
challenges are interoperability and operational complexity due
to the technological heterogeneity of InfSPs. Several studies
(e.g., [1], [2]) and initiatives such as OpenStack, Kubernetes
[3], etc., address these challenges. In reality, the primary
challenges hindering the creation of large-scale federations
of InfSPs are business-oriented and relate to aspects such as
economics, trust, privacy, and governance. In particular, in the
federation solutions proposed in the related literature [4]–[9]
and commercial federations that exist, such as OnApp [10],
Google Anthos [11], HPE Cloud28+ [12], etc., InfSPs have to
share sensitive information with a central trusted entity (e.g.,
a Broker) or other InfSPs in the federation (decentralized ap-
proaches). This can raise concerns about privacy and security,
as well as of validity of information collected from multiple
and usually competing entities. Blockchain-based solutions are
appealing for the trustworthy management of such federations
due to inherent properties such as decentralization, privacy,
transparency, verifiability, etc.
Our contribution. In this paper, we model the collec-
tive service provisioning in InfSP federations and introduce
mechanisms and policies for the (i)trustworthy decentralized
allocation of federated resources to VSP service requests and
(ii)fair distribution of total federation profits to InfSPs. The
resource allocation problem is formulated as a sealed-bid
reverse auction, with InfSPs bidding for their resources’ usage,
aiming to maximize the total federation profit. Recognizing
*Accepted for publication to CCGrid 2024*
the NP-hardness of the winner determination process, we
introduce a polynomial-time heuristic with two phases: the
opportunistic and adjustment phases. For determining prices
paid by VSPs and compensations for InfSPs, we introduce
a novel hybrid mechanism incorporating the well-known
Vickrey–Clarke–Groves (VCG) [13] and first-price auction
[14] mechanisms, alongside a sophisticated blockchain-based
federation wallet management mechanism, serving as a sink
for the federation revenues. This hybrid approach, coupled
with the unique characteristics of our blockchain-based im-
plementation, exhibits properties that neither VCG nor the
first price can achieve alone, such as truthfulness, efficiency,
fairness, individual rationality, trustworthiness, commitment
non-repudiation, public winner verifiability and bid privacy.
The rest of the paper is organized as follows: In Section
II, we model service provisioning in a decentralized feder-
ated platform for InfSPs. In Section III, we introduce our
mechanisms and policies for the trustworthy and efficient
management of InfSP federations, providing decentralized im-
plementation insights. In Section IV, we present our numerical
analysis. In Section V, we overview the relevant literature, and
in Section VI, we present our conclusions.
II. SY ST EM MO DE L
Resources. Let Idenote the set of InfSPs who form a
federation in order to combine their resources for jointly
supporting the provisioning of different kind of services,
offered by VSPs (Fig. 1). The resources can be of any type,
e.g. computational, network, storage, IoT devices, etc., each
of them suitable to serve different needs from a service
point of view. If Rdenotes the set of collective resources,
each InfSP i∈ I maintains a set of resources Ri(where
R={R1∪ R2∪... ∪ R|I| }) that may be located on different
geographic regions. Therefore, each resource ris assigned
to a certain resource type tr∈ T and geographic region
ℓr∈ L. Given that InfSPs have limited amount for each
type of resources in each region, we assume that each InfSP
ihas a maximum capacity C(i, t, ℓ)of resources of type t
in geographic region ℓ. For instance, regarding computational
resources, this maximum capacity refers to the total CPU
power available through VMs or containers. We denote the
set of all capacity values in the system as C.
Service components. A service sis composed of a set of N
service components, i.e., s={σ}N. A service component σ
implements a discrete “function” of a service that is facilitated
by a certain type of resource. Thus, multiple resources are
combined for supporting a service. Considering the example of
a video streaming service, a service component can be a piece
of software that performs encoding on the video data. In this
case, the encoding service component needs to be deployed at
the edge of the network, i.e., in the geographic region of the
source that generates the content, and requires a VM/container
resource of adequate CPU power for completing the encoding
task in the required level of Quality of Service (QoS). Each
service component σ∈sis enabled by a single resource r
that satisfies the service component requirements in terms of
Fig. 1. Federation of InfSPs.
the type of resource t(σ)∈ T that needs to be assigned and
the region where this resource is located ℓ(σ)∈ {L ∪ 0}. If a
service component σdoesn’t need to be served by a resource
in a specific geographic region, parameter ℓ(σ)is set to 0.
Service load. Each service generates a load for the under-
lying resources assigned to it. The load of each service is
defined at the level of each service component σ∈s, i.e
λσ. Note that the load λσmay be a vector of multiple load
attributes. Different load attributes are relevant for each type
of service component. Accordingly, the capacity of a resource
is characterized by a set of such attributes. In fact, resources
and services components that are relevant to each other are
characterised by the same set of load/capacity attributes. Such
attributes are vCPU power, memory size, volume of data
stored, messages send from/to IoT devices, etc. An attribute
may be utilized for determining (i)the scaling of a resource
allocated to a service component, (ii)the price to be charged
for the resource provided or (iii)both. The load λσof a
service component σis exclusively served by a single resource.
Pricing of resources (Bidding). The resources required for
composing a service may be contributed by different InfSPs.
When registering the resources to the federated platform,
InfSPs announce a bid br(λσ)for each resource rthey own,
as the minimum compensation (in $/sec) they are willing to
receive each time the resource is allocated to any service
component σ. The bid is a function of the load λσthat the
service component generates for the resource.
Service Request Pricing: For each service request ssub-
mitted by a VSP to the federated platform, the VSP specifies
a price, ˆps(in $/sec), that it is willing to pay if the requested
service is provisioned. The service is provisioned if the total
cost of required resources, i.e., sum of bidding functions
br(λσ)for involved resources, and an additional charge from
the decentralized federation platform, pm, do not exceed the
VSP’s willingness-to-pay, ˆps. The pmcharge supports the
operational expenses of the decentralized platform.
A. Real-world Service Example
Next, we elaborate on a real-world service example inspired
by the AWS Connected Mobility Solution [15]. As illustrated
in Fig. 2, a VSP in the automotive industry (e.g., a car man-
ufacturer) offers a complete connected mobility service that
2
Fig. 2. Connected automated mobility service example. Service components may be deployed across different geographic regions and InfSPs.
includes on-the-move capabilities such as navigation, location-
based services, remote vehicle diagnostics, media streaming,
etc., along with functionalities related to the vehicle lifecycle
such as predictive analytics, maintenance alerts, etc.
Service components and associated resources. Vehicles are
equipped with sensors that collect data related to the vehicle
and surroundings. The collected data are delivered from the
vehicle devices to the other components of the service through
a Radio Access Network that provides coverage across the
transport corridors. Therefore, adequate radio resources from
multiple antennas located on different regions need to be
allocated. In addition, certain service components that are
responsible for data collection, streaming, processing, event
detection and decision making should be placed in a central
cloud as well as in different geographic regions and close to
the vehicles, i.e. at the edge of the network, for achieving the
necessary QoS. For these tasks, resources related to IoT, data
streaming, event detection, data storage, analytics and fleet
management, should be utilized.
Service Requests. Multiple automotive VSPs submit service
requests to the decentralized federated platform, identifying
the geographic regions where they would like to have presence.
This request determines the number of edge regions and,
consequently, the edge-site service components that should be
enabled. The load for each service component in each region
should also be specified. For example, if we assume that the
IoT component is enabled by the AWS IoT Core resource,
then the service component is characterized by four load
parameters; namely connectivity, messaging, device registry,
and rule engine loads [16]. Finally, the VSP should express
its willingness-to-pay at the level of the service as a whole.
Resource bidding. Each InfSP announces a bid
br(λσ)for each owned resource rthat identifies the
compensation the InfSP is willing to accept if the resource
is allocated to any service component σ. Considering
again the example of AWS IoT Core resource [16],
the input load for the bidding function is represented
by a vector of the four load attributes, that is, λσ=
[connectivity, messag ing, device registry, rule engine].
For instance, the connectivity load is defined as the “minutes
of connection”, which accounts for the active connection time
of all IoT devices assigned to an IoT Core component. To
illustrate, if we assume that 10,000 devices were constantly
connected in an one month period, then the total amount
of connection minutes would be 432 millions. Assuming
a connectivity charge of 0.08$ per million minutes of
connection, the monthly charge for connectivity alone would
be 34.56$. Note that this price will increase when considering
other load parameters. By combining the bidding functions
of all resources comprised in a service, we can estimate the
total cost for enabling the service.
III. FED ER ATIO N MECHANISMS AND POLICIES
A. Resource Allocation Policy
The federated platform operates assuming service provision-
ing periods, i.e the resource allocation is updated periodically
in fixed time windows or when a significant mass of new
service requests has arrived to the platform. The resource al-
location for the new-coming services requests Sis determined
based on the current resource availability. Given that some
resources may be occupied from previous service provisioning
periods, only part of each resource may be available. In this
study we assume that resources of a service are not reallocated
until they are released.
Let Xdenote the set of binary decision variables that
determine which resources will contribute to each service
component σ. In particular, the binary variable xr,σ ∈X
determines whether resource rcontributes to service compo-
nent σ(for xr,σ = 1) or not (for xr,σ = 0). Considering
a set of service requests Salong with the respective VSP
willingness-to-pay ˆpsfor each service s∈Sand the resource
bids b={br(λ)}r∈R of the InfSPs, we formulate the
resource allocation problem. The objective of this problem
is the maximization of the total federation profit, i.e., the
difference between the revenues that come from the payments
(willingness-to-pay) of VSPs and the costs (bids) of InfSPs for
the resources utilized to enable the services. The total revenue
of the federation is given by the following formula:
U(X) = X
s∈S
X
σ∈s
X
r∈R
xr,σ
|s|ˆps,(1)
which aggregates the willingness to pay for all requests in S
that are eventually served. The value of xr,σ
|s|equals 1for the
services that are provisioned and 0for those that are not.
The total cost of the federation is the cost of all InfSPs for
contributing resources to the provisioned services. Considering
that the bids b={br(λ)}r∈R of InfSPs for the different
resources reflect their cost, the total federation cost is
K(X,b) = X
r∈R
X
s∈S
X
σ∈s
xr,σ br(λσ).(2)
3
Note that the bidding functions announced by the InfSPs may
not be by-default truthful, i.e. reflect their actual costs. Proper
mechanisms should be in place in order to guarantee the
truthfulness of InfSPs (see Section III).
The total federation profit maximization problem is formu-
lated as follows:
max
XU(X)−K(X,b)(3)
s.t. X
σ∈s
xr,σ ≤1,∀r∈ R,∀s∈S(3a)
X
r∈R
xr,σ ≤1,∀σ∈s,∀s∈S(3b)
X
r∈Ri
X
s∈S
X
σ∈s
xr,σ λσz(r, t, ℓ)≤C(i, t, ℓ),(3c)
∀i∈ I,∀t∈ T ,∀ℓ∈ L
X
r∈R
X
σ∈s
xr,σ =X
r∈R
xr,σ′|s|,∀σ′∈s,∀s∈S(3d)
xr,σ tr=xr,σ t(σ),∀r∈ R,∀σ∈s,∀s∈S(3e)
xr,σ ℓr−ℓ(σ)ℓ(σ) = 0,∀r∈ R,∀σ∈s,∀s∈S(3f)
X
σ∈s
X
r∈R
xr,σ br(λσ) + pm≤ˆps,∀s∈S(3g)
Constraints (3a) and (3b) ensure that each resource con-
tributes to at most one service component of each service, and
each service component is served by at most one resource of
the appropriate type, respectively. For a single InfSP, constraint
(3c) ensures that the load generated by service components,
enabled by resources of a certain type in a specific geographic
region, doesn’t exceed the maximum capacity available to the
InfSP. Note that the function z(r, t, ℓ)is an indicator function
that returns 1if the type and region of resource requals t
and ℓ, respectively; otherwise, it returns 0. Constraint (3d)
guarantees that resources will be allocated to either all or none
of the service components for each service, not in a subset of
them. Constraints (3e) and (3f) ensure that a resource of the
appropriate type, located in the appropriate geographic region,
will be allocated to each service component. Finally, constraint
(3g) ensures that the cost for providing each service does not
exceed the willingness-to-pay of the requested VSP.
The combinatorial optimization problem described falls
under the category of facility location problems, acknowledged
as NP-hard [17]. While optimization tools such as the Gurobi
Optimizer [18] can effectively handle small instances, com-
putational time grows exponentially with system scaling. Im-
portantly, these solvers cannot be integrated into decentralized
platforms based on blockchain technology due to the absence
of support for on-chain solutions in smart contract languages.
In this paper, drawing inspiration from the Martello-Toth
approximation scheme for Generalized Assignment Problems
[19], we propose a polynomial-time greedy algorithm that can
be implemented within a smart contract.
Greedy Algorithm. Our greedy algorithm relies on three key
notions, namely the cost, value and desirability, as introduced
by [19]. In our case, the cost for enabling a service component
σis determined by the bidding function of the resource rthat
Algorithm 1: Opportunistic phase
1¯
S:= S// Currently unserved services
2while ˆ
S=¯
Sdo
3¯
S:= ˆ
S
4winning value := −1
5winning pair := {}
6foreach s∈ˆ
Sdo
7foreach σ∈sdo
8foreach r∈ R do
9if λσ≥Crand ˆps,σ ≤br(λσ)then
10 continue
11 if tσ=trand lσ=lrand lσ= 0 then
12 continue
13 Rσ.append(r)
14 dr,σ =ps
|s|br(λσ)
end
15 r∗
σ= arg maxr∈Rσdr,σ
16 r′
σ= arg maxr∈{Rσ\r∗
σ}dr,σ
17 MDσ(r∗
σ, r′
σ) = dr,σ∗−dr,σ′
18 if winning value ≤MDσ(r∗
σ, r′
σ)then
19 winning value := MDσ(r∗
σ, r′
σ)
20 winning pair := {r∗
σ, σ}
end
end
21 if winning pair ={} then
22 update X,¯
S,¯
Cr∗
σ,ˆps,σ
end
is associated to the service component, i.e. cr,σ =br(λσ). On
the other hand, the value that the enablement of a service
component brings to the federation is associated with the
willingness to pay ˆpsthat is attached to the requested service
s. In particular, the value of service component σthat belongs
to service sis given by vσ=ˆps
|s|. This means that all service
components are equally useful for the provision of the service.
Finally, the desirability for enabling a service component σ
through a resource rexpresses the proportion of the value
that is generated per unit of cost, i.e., dr,σ =vσ
cr,σ =ˆps
|s|br(λσ).
Our algorithm consists of the two following phases:
1) Opportunistic phase: In this phase, our algorithm it-
erates until all services are enabled or no further feasible
resource allocations exist (step 2). In each iteration, the
algorithm explores potential pairs of resources and service
components (steps 6−8) and performs the most “desirable” al-
location. Initially, for each service component σ, the algorithm
assesses the feasibility of all resources concerning capacity,
cost, type, and location (steps 9−12). Note that ˆps,σ (step 9)
represents the proportion of the remaining budget of service
request sthat can be spent on service component σ. This
accounts for the fact that part of the initial budget ˆpsfor
a service smay have been spent in prior iterations. If we
denote by ˆps′the portion of ˆpsreserved to serve a subset
s′of service components of service s, then the remaining
proportional budget is estimated by ˆps,σ =ˆps−ˆps
′−pm
|s|−|s′|.
4
The algorithm creates a list with all feasible resources (step
13) for a service component σand calculates the “desirability”
score dr,σ for each of them (step 14). Next, the two resources
with the highest desirability score are selected (steps 15−16).
Assuming that r∗
σand r′
σdenote the two most “desirable”
resources, the difference between their desirability scores,
i.e., the marginal desirability, denoted as MDσ(r∗
σ, r′
σ)is
estimated (step 17). If this calculated marginal desirability
is the highest that has been calculated in the iteration, the
winning pair and score are updated (steps 18 −20). After
evaluating all pairs of service components and resources, the
resource allocation of the winning pair is performed and the
necessary parameters are updated for the next iteration (steps
21 −22). Intuitively, the algorithm selects to serve the service
component that will potentially suffer the highest desirability
loss if not served in the current iteration. Our Opportunistic
phase has a complexity of O(|S||s||R| log |R|).
2) Adjustment phase: This phase, not part of the Martello-
Toth algorithm, is introduced to capture the specificities of
our problem, stemming from the fact that each service con-
sists of multiple components. During the Opportunistic phase,
resource allocation decisions are made without considering
the service to which each service component belongs. Con-
sequently, certain resources may be allocated to incomplete
services, where only a subset of the components is enabled.
Since incomplete services cannot be provisioned, related re-
source allocation decisions need to be reversed. In this phase,
unserved services are prioritized based on the number of
components left unserved during the Opportunistic phase.
Resources allocated to the components of incomplete services
are then released. Starting with the unserved service with the
smallest number of unserved components, our algorithm aims
to completely serve as many services as possible. In each
iteration, only the service components of a single service
are considered, and the algorithm aims to allocate feasible
resources at the lowest cost. If, at the end of an iteration, the
service remains incomplete, it is marked as infeasible, and
resource allocation decisions are reversed. The complexity of
the Adjustment phase is O(|S||s||R|).
B. Price Determination and Revenue Sharing Mechanism
Even if the resource allocation problem (3) is optimally
solved to maximize the total profit of the federation, the
determination of payments from VSPs or compensations for
Individual InfSPs is not addressed by the solution. In this sec-
tion, we introduce a hybrid price determination and revenue-
sharing policy that combines VCG and first-price auction
mechanisms, coupled with a sophisticated federation wallet
management policy that oversees the revenues of the federation
across multiple provisioning periods. Initially, we apply the
VCG mechanism because it maximizes the profit for InfSPs,
inheriting the desirable properties of VCG [13], including
efficiency of outcome, truthfulness of InfSPs, and fairness in
revenue distribution. Conversely, the use of a first-price auction
ensures that InfSPs can recover their expenses, while VSPs
may benefit by receiving a payment discount in the process.
Below, we describe how the VCG mechanism is applied in
our case and how potential budget imbalances and individual
InfSP profit losses are mitigated with our federation wallet
management policy. Finally, we present the modified first-price
auction mechanism as a fallback solution when the revenues
in the federation wallet are insufficient for applying VCG.
1) VCG mechanism: Under VCG mechanism, for each
service sprovisioned the customer VSP pays its willingness
to pay ˆps. Consequently, the total revenue U(X∗)obtained by
the federation for the provisioning of all services Sis given
by (1). On the other hand, the cost Ki(X∗,bi)of InfSP i
for the resources Ricontributed to the federation, under its
announced bids bi={br(λ)}r∈Riand optimal allocation X∗,
is given by formula (2) when considering only InfSP i.
The earned revenues are distributed to all InfSP following
the VCG payments. In particular, the compensation of InfSP
ireflects the “social benefit” that its presence brings to
the federation. Hence, the VCG payment for an InfSP iis
determined by the total profit of federation when iparticipates,
without accounting the contribution of iin the total cost, minus
the total profit of the federation when idoes not participate. If
we use X∗
−ito denote the optimal resource allocation policies
when InfSP idoes not participate in the service provisioning
and U−i(X∗
−i)the total generated profits in this case, then
VCG payment of InfSP iis given by
pi(b) =U(X∗)−X
j=i
KjX∗,bj
−U−i(X∗
−i)−X
j=i
KjX∗
−i,bj(4)
Non-cooperative bidding game. Given that the compensa-
tion of InfSPs depends on the bids announced b, we assume
all InfSPs Iparticipate in a non-cooperative game, where
MNOs strategically announce their bids b, each of them
aiming to maximize its own payoff. In particular, each InfSPs
idetermines its bids by solving the following problem:
arg max
bipi(b)−KiX∗,bi .(5)
That is the difference between the compensation that ireceives
from the federation and i’s cost under the resource allocation
determined by the solution of problem (3).
Theorem 1. (Truthfulness) If the compensations of InfSPs are
determined by VCG payments (4), then the truthful behavior
of InfSPs when announcing the bids is a Nash Equilibrium.
Property 1. (Weak Budget Balance Property) The total rev-
enues of the federation is sufficient to cover the total compen-
sations of all InfSPs when the net benefit generated by the fed-
eration is greater than the aggregate marginal contributions of
InfSPs plus the transaction fees of the decentralized platform,
i.e., when U(X∗)−P
i∈I
Ki(X∗)≥P
i∈I
MCi+Pm(X∗).
Note that the total transaction fees collected by the federated
platform are given by:
Pm(X∗) = X
r∈R
X
s∈S
X
σ∈s
xr,σ pm.(6)
5
The proofs of Theorem 1 and Property 1 are available as
supplementary material1.
As shown in Section IV, Property 1 holds in in a variety of
cases, indicating the sufficiency of VCG payments. However,
this is not universally true. Qualitatively, this property does not
hold in topologies where the majority of geographic regions
are dominated by a single monopolistic InfSP. For example,
consider an extreme scenario where all VSP services enabled
by the federation must traverse a region with only one available
InfSP i. Then, the marginal contribution of ito the total profit
of the federation is U(X∗)−P
i∈I
Ki(X∗), leading to zero total
profit when iis removed. In this example, Property 1 does not
hold, even when considering only the marginal contribution
of i. While the example illustrates an extreme scenario with
all services passing through the monopolistic InfSP, a crucial
observation is that in topologies with region monopolies,
relying solely on a standalone VCG mechanism may not be
sufficient. For this reason, we introduce the following step by
which we take care of cases where VCG alone falls short.
2) Federation wallet management: In several cases Prop-
erty 1 will hold and there will be a surplus of money stemming
from VSP payments that is not allocated to the InfSPs through
the VCG mechanism. To preserve the truthfulness of VCG
mechanism, it is imperative that the distribution of this surplus
remains independent of the outcome of VCG. According to
[20], the truthfulness of the VCG mechanism is maintained
when assigning the surplus to a designated sink entity that is
not involved in the resource allocation decisions. To this end,
we introduce the following innovative approach: we designate
the decentralized platform as the sink entity responsible for
storing and releasing potential surplus using a federation
wallet. A federation of InfSPs is implemented as a Decen-
tralized Autonomous Organization (DAO) [21], [22] and the
management of the federation wallet is governed by mutually
agreed rules among members of DAO. The management of
wallet is enabled by instances of Auction Smart Contracts
(ASCs), as explained in Section III-C.
In cases where Property 1 is not met, the payments from
VSPs fall short of covering the expenses of InfSPs. Our wallet
management policy is designed to address this deficit by lever-
aging surplus accumulated in the federation wallet, ensuring
budget balance. Additionally, the policy must consider that an
essential requirement for InfSPs to join the federation is the
assurance that their individual profits in each service provi-
sioning period will exceed those from independent operation
(individual rationality). Therefore, the surplus maintained by
the decentralized platform primarily aims to consistently fulfill
this condition. If the surplus surpasses a predefined threshold,
an extra portion may be distributed among federation members
(participation incentive).
Let ψdenote the balance of money maintained in the
federation wallet at any given time. In a provisioning period,
the decentralized platform determines resource allocation by
1https://auebgr-my.sharepoint.com/:b:/g/personal/ntarzanos aueb gr/
Ea9YuM713QVHgcezmwZRnnQBywjcFswk9WQN2o1glMDJxg?e=aB7pZx
solving problem (3), estimates the VCG payments of InfSPs,
denoted as [p1(b),p2(b), ..., p1(b)], and it updates the balance
ψof smart contract based on the surplus/deficit of the current
provisioning period. Next, the decentralized platform follows
the two steps below for the surplus/deficit management.
STEP I - Guaranteed profitability. Let ¯
Pirepresent the profit
that InfSP iwould attain if it were to operate independently
(standalone) in the current provisioning period. In order to
incentivize InfSP ito participate in the federation, the compen-
sation provided by the decentralized platform should ensure
that InfSP iachieves at least the same level of profit as ¯
Pi. If
the payment determined by the VCG mechanism falls short,
the difference should be covered by the surplus maintained in
the federation wallet. In the case where the standalone profit
Pi(X∗,b)of InfSP iis higher that the one achieved by the
VCG payment pi(b), the final payment should be adjusted to
p∗
i=pi(b) + ¯
Pi−Pi(X∗,b).(7)
STEP II - Conditional surplus release. Assuming that the
federation has established an upper “safety” threshold ψtto
ensure that sufficient money are stored in the federation wallet
for effectively handling potential deficit events, any surplus
beyond this threshold should be evenly distributed among
the federation members. The even distribution maintains the
truthfulness obtained by using VCG and can be consider as a
federation participation reward.
In cases where our wallet management policy fails to
address budget balance and individual rationality, our solution
resorts the first price auction mechanism outlined below. Such
cases arise in topologies where the application of VCG always
results in a violation of Property 1 and, consequently, in a
deficit.
3) Modified first price auction mechanism: Under this
mechanism, for each service request sthe InfSPs will be
compensated with the sum of their bids of the resources con-
tributing to this service. Consequently, the total compensations
K(X∗,b)of InfSPs is given by (2), while the individual
compensations can be calculated by the same formula when
considering only the resources owned by the relevant InfSP.
By definition the willingness-to-pay of VSPs is higher than
the sum of bids of the resources contributing to the service.
Therefore, the total payments from VSPs will be always higher
than the total compensations of InfSPs. This means that when
applying first price auction the federation will always have
a surplus to be stored in the federation wallet. However, in
this modified first price auction mechanism we assume that
part of the surplus can be given to the VSPs in the form of
a discount. Note that the compensation Pm(X∗)of federated
platform should be also taken into account. We use parameter
ϵto determine the ratio based on which the surplus is split
between the federation and VSPs, e.g., e= 0.7means that
federation receives 70% of the surplus. The federated platform
will store a surplus of
Cf(X∗,b) = ϵ[U(X∗,b)−K(X∗,b)−Pm(X∗)].(8)
6
On the other hand, if S′denotes the number of services that are
eventually enabled, each customer VSP gets a price discount
ds(X∗,b) = (1 −ϵ)[U(X∗,b)−K(X∗,b)−Pm(X∗)]
S′,(9)
which means that the final price for service sis ˆps−ds(X∗,b).
Note that the truthfullness introduced by the VCG mecha-
nism is maintained for our hybrid solution since the InfSPs do
not have the necessary information (service requests, resource
availability, bidding function, etc.) for extracting whether first
price auction will be applied in any given iteration.
C. Blockchain Implementation
By implementing our sealed-bid reverse auction for federa-
tion management on blockchain, we can achieve several desir-
able properties, namely trustworthiness without trusted third
parties, bid privacy, public verifiability and non-repudiation,
as follows. We consider that Ethereum or an Ethereum VM
compatible blockchain is employed. Each of the VSPs and
InfSPs has an account (i.e., a public-private key pair) in its
wallet with a certain address (i.e., the last 20 bytes of the hash
of its public key). Each InfSP (resp. VSP) account is associated
to a budget balance, but also different balances for the different
resources it offers (resp. allocates). Each different resource
type is digitally represented by an NFT (i.e., ERC-721) that
contains all the different characteristics of the resource, i.e.,
type, capacity, location, etc. Upon resource allocation, the
respective NFT of the resource changes owner. Each such NFT
has a special public function that, if called, it checks a timer
from the allocation of this resource and upon a certain timeout
it transfers ownership back to the InfSP where it belongs. Note
that, in blockchain, each stakeholder is pseudonymous, but it
can be easily mapped to a specific entity, if its public key is
known.
The federated auctioneer is implemented in the blockchain
as an Auction Smart Contract (ASC) that owns the federated
wallet. Since we employ a sealed-bid reverse auction mecha-
nism for resource allocation, it is imperative that bids remain
confidential until winner determination. Furthermore, for non-
repudiation reasons, it is necessary for bids (and resource
offerings) to be collateralized, by means of assets or funds.
Various approaches have been proposed to implement
sealed-bid auctions in a decentralized manner, as explained in
Section V. For collateralization of bids and resource offerings,
we follow a Zether-like approach [23], where, initially, each
InfSP that offers resources creates an account, transfers to
that account all allocatable resources and locks its account
to the ASC. Each bidder creates a new account and transfers
to that account its bid in an encrypted form (using Elgamal
encryption) and locks that new account to the ASC, thus
achieving full bid confidentiality. After the bidding phase, a
bidder can open its bid by also providing it along with a
Zero-Knowledge Proof (ZKP) [24] on its encrypted bid, so
that its previous commitment to the auction can be verified by
the ASC. Therefore, winner determination can be performed
and it can be publicly verifiable. The ASC can then simply
transfer the value from the VSPs to the federation wallet and
the winner InfSPs, transfer allocated resources of the winner
InfSPs to the VSP, and unlock unused willingness to pay of the
VSP, the accounts of all losing bids, and any unused resources
of the winning InfSPs. Note that an ASC factory (i.e., a
special smart contract) for creating multiple ASC instances
can be implemented, so that multiple auctions to be able to be
executed in parallel without any resource or budget conflict.
IV. NUMERICAL EVALUATION
We develop a Python program that sets up an environ-
ment of multiple federated InfSPs maintaining infrastructure
across multiple regions and a set of VSPs generating service
requests. We consider random topologies and also introduce
randomness in assigning resource capacities to each InfSP.
In order to introduce asymmetries, we explore both “large”
and “small” resource profiles for InfSPs. Our study focuses
on the demonstration of (i)the performance of our greedy
algorithm against the optimal allocation, (ii)the additional
monetary benefits of InfSPs by participating in the federation
(iii)truthful behavior of InfSPs when it comes to resource
bidding and (iv)the robust operation of our hybrid revenue
sharing and price determination mechanism across multiple
provisioning periods.
A. Simulation Setup
Topology. We investigated topologies of [3,5,10,15] InfSPs
dispersed in either [2,3,5] geographic locations. In each topol-
ogy, an InfSP have presence to at least one randomly selected
region. Additional regions are added with a probability of 0.35,
which is determined in a per region basis.
Resource types and capacities. In our evaluation, we focus
on AWS’s connected automated mobility service discussed in
Section II-A, specifically focusing on three key resources: IoT,
data streaming, and analytics. In each region that an InfSP
is present may have a “small” or “large” resource profile. A
provider has a “large” profile with 35% probability. “Small”
profile resource capacities follow a normal distribution with
standard deviation of 0.3, and mean values of [10.000 IoT
devices, 200 TBs, 1.000 vCPUs], for IoT, data streaming and
analytics resources, respectively. Large profile mean values are
[50.000 IoT devices, 1000 TBs, 5.000 vCPUs].
Resource bidding. For resource bidding assignment, we
refer to publicly available AWS pricing. The IoT resource
bid is based on device connection minutes (0.08$ per million
minutes)2. Data streaming depends on ingested data load
(0.25$ per GB)3, and analytics resource bid is driven by the
the number of vCPUs utilized by EMR and EC2 instances
(0.5$ per hour per instance)4.
Service Requests. We evaluated our mechanisms with low,
medium and high demand loads, by generating various service
requests bursts. Each burst arrives within a single provisioning
period of the decentralized platform, with request numbers
2https://docs.aws.amazon.com/iot/latest/developerguide/iot-price.html
3https://aws.amazon.com/kinesis/data-firehose/pricing/
4https://aws.amazon.com/emr/pricing/
7
(a) 3 InfSPs, 3 Geographic regions (b) 5 InfSPs, 5 Geographic regions (c) 10 InfSPs, 10 Geographic regions
Fig. 3. Performance of our Greedy against the optimal resource allocation, in terms of the achieved total benefit (i.e. profit) generated for the federation. The
percentages identify the portion of total requests finally served for each different service request load scenario (10 to 200 requests).
Fig. 4. Truthful announcement of costs is the dominant strategy for each
InfSP. Higher or lower cost declaration leads to profit loses.
ranging between 5to 200. Each randomly generated service
request requires presence to at least two geographic regions.
An additional region is added with 20% probability. The
load for each service component is determined by a normal
distribution with standard deviation 0.1and with mean values
[1000 IoT devices daily connected , 10 TBs streamed per
day, 100 vCPUs per hour/ day]. Each requests scomes with
the price ˆpsthat the respective VSP is willing to pay, which
again is determined by a normal distribution with a deviation
of 0.1and mean value of price 600$/hour, which increases
proportionally to the number of additional regions.
Decentralized federated platform. We assume platform fee
of 0.01$ per transaction.The monetary threshold for the fed-
eration wallet, triggering surplus distribution to the federation
members, is set to 15000$. We set ϵ= 1, indicating that when
the modified first price auction is employed, VSPs receive no
discount, and all the surplus is stored to the federation wallet
to be distributed in subsequent provisioning periods.
B. Numerical Results
Greedy. Figure 3 illustrates the performance of our greedy
algorithm compared to the optimal resource allocation deter-
mined by the Gurobi Optimizer [18]. Specifically, it displays
the total profit generated for federated InfSPs across different
topology dimensions: 3,5, and 10 dispersed in 3,5, and
10 regions, respectively. Each InfSP may have a presence
in multiple regions. The greedy algorithm’s performance is
evaluated against the optimal allocation for various service
request loads, ranging from 10 to 200 service requests. The
results demonstrate that our greedy algorithm achieves optimal
resource allocation when there is sufficient resource availabil-
ity to meet the incoming demand (i.e., more than ≈90% can
be served). Given that cloud resource are usually assumed to
be “infinite”, this is expected to be the most typical case.
However, when it come to the “edge” the resource infinity
assumption may not be always realistic. As shown in Fig. 3,
even in such cases, our greedy algorithm achieves an allocation
really close the optimal one, with the worst case scenario
being when only almost half (≈55%) of the service demand
can be served, resulting in ≈1% less profit. Importantly, the
efficiency of our greedy algorithm appears unaffected by the
size of the topology or the number of requests.
Truthfullness. The adoption of the VCG mechanism en-
sures that InfSPs declare their actual costs when bidding for
resources, and the resulting profit is fairly distributed among
them. Figure 4 illustrates the profit of an individual InfSP
when truthfully declaring its actual cost compared to scenarios
where it unilaterally deviates by declaring a higher or lower
cost. The results demonstrate that maximum profit is achieved
when truthful information is provided.
VCG weaknesses. The VCG mechanism alone cannot
guarantee that in each provisioning period the payments of
VSPs will be adequate to cover the payments of InfSPs
(budget imbalance). Figure 5 shows the total surplus or
deficit incurred after applying VCG for 18 topologies (rep-
resented with different colors) and for various service loads
[5,10,20,30,50,70,100]. Three types of topologies emerge:
(i)those where the VSP payments always cover the InfSP
payments (surplus), e.g. topology 14, (ii)those that may have
surplus or deficit depending on the load, e.g. topology 13, and
(iii)those that always have deficit, e.g. topology 6. However,
even in the case where a surplus is achieve, it is not guaranteed
that the VCG calculated payments result in a profit for each
individual InfSP greater or equal to their standalone profit (lack
of individual rationality). This is depicted in Fig. 6, where,
for instance, at load of 50 requests, the standalone profit of an
InfSPs surpass its profit when in federation with only VCG
applied. Our mechanism addresses these shortcomings.
8
Fig. 5. Surplus or deficit generated when applying VCG mechanism alone -
18 topologies for 7 different service loads.
Fig. 6. Individual InfSP profit when (i)operating alone, (ii)operating
in VCG only federation and (iii)operating in federation that adopts our
complete solution. Our mechanisms guarantees individual rationality.
Budget balance and individual rationality assurances. Our
mechanisms guarantees that InfSPs participating in a federa-
tion only gain additional profit without incurring losses. Figure
6, illustrates how our budget imbalance mitigation mechanism
addresses the individual rationality weakness by using surplus
from previous provisioning periods, guaranteeing no losses for
all InfSPs. However, maintaining sufficient surplus in the fed-
eration wallet is crucial for this assurance. In cases of deficit-
prone topologies, such as those with perpetual deficits (e.g.,
topology 6 in Fig. 5), or topologies with more deficits than sur-
pluses, there may be provisioning periods where the federation
wallet lacks funds to ensure budget balance and individual
rationality. Our hybrid solution resolves these situations by
employing the modified first-pricing auction mechanism as a
fallback solution. This mechanism compensates InfSPs with
their bid (minimum payments) and generates a surplus added
to the federation wallet for subsequent provisioning periods.
Robustness. Unlike previous figures illustrating our solu-
tion’s operation for a single provisioning period and different
service request loads, Fig. 7 showcase the complete solution’s
performance over 30 consecutive provisioning periods with
a number of randomly generated requests in each period. We
evaluate multiple randomly generated topologies (over 50). For
simplicity, we assume that provisioned services do not span
multiple provisioning periods. The focus is on tracking: (i)
the balance of the federation wallet, (ii)whether the VCG
or first-price auction mechanisms are employed, and (iii)
whether individual rationality for InfSPs is guaranteed in each
provisioning period. The results demonstrate the robustness of
our mechanism over multiple provisioning periods, effectively
managing the federation wallet to generate additional profits
for InfSPs. For demonstration, we present results from two
indicative topologies with 5 InfSPs operating in 3 regions.
As shown in Fig. 7, for topology 1 the VCG mechanism
is consistently applied across all 30 iterations, indicating
that this example belongs to the category of topologies with
perpetual surplus. Notably, at 12th provisioning period, the
surplus reaches the balance threshold, leading the federation
to distribute the additional surplus generated per iteration.
On the other extreme, topology 2 exhibits constant deficit.
Without our solution, in such extreme cases, only the first
price auction mechanism would be viable. However, with our
mechanism storing surplus to the federation wallet in each
iteration where the first price is applied, it becomes possible to
employ the VCG mechanism in several provisioning periods,
significantly increasing InfSPs’ profits. The majority of the
topologies investigate fall between these two extremes, i.e.,
they were VCG dominant with the first price mechanism only
employed in a few provisioning periods. In terms of individual
InfSP profit, the results reveal individual rationality is always
satisfied. InfSPs facing limitations in standalone operation,
such as geographic coverage constraints, can experience signif-
icant benefits. Conversely, InfSPs already enjoying substantial
profits in standalone operation can also generate additional
significant profits through federation participation.
C. Lessons Learnt
Our greedy algorithm achieves optimal resource allocation
when the available federated resources can accommodate up
to 90% of submitted service requests. Even in more congested
scenarios, the algorithm maintains an allocation close to op-
timal, with a maximum gap of approximately ≈1%. Our
hybrid mechanism ensures the truthfulness of InfSPs, as the
dominant strategy is to reveal their actual cost during resource
bidding; deviating from this strategy results in a profit loss.
Implementing our complete solution maximizes both the total
federation profit and individual profits for each InfSP. The
VCG mechanism alone cannot ensure budget balance and
individual rationality of InfSPs. Combining VCG with our
federation wallet budget imbalance mitigation mechanism and
the modified first-price auction mechanism is essential for the
robust operation of the federation under any circumstances and
across provisioning periods.
V. RE LATE D WOR K
Various early studies [1], [2] introduced the concept of
cloud federation, emphasizing architectural, technical, and
interoperability aspects. More closely related to our work,
several studies delve into economic policies for resource allo-
cation and revenue distribution in cloud federation. In [4], [5]
coalitional game theory is applied to form profit-maximizing
federation among cooperative cloud providers. The authors
of [6]–[9] introduce economic policies for federations in a
non-cooperative environment where providers act selfishly. All
9
Fig. 7. Federation wallet balance across multiple provisioning periods, capturing whether VCG (V mark) or first price (F mark) mechanism is employed.
Two selected topologies of 5 InfSPs, in 3 Geographic regions for 30 Iterations.
above approaches often require the existence of a central entity
or coordination among providers for their enforcement, leading
to the revelation of sensitive information. The concept of feder-
ation in the networking domain encompasses traditional forms
like roaming or peering, and recent approaches such as col-
laborative provisioning of virtual networks or network slices,
spectrum or infrastructure sharing, etc. The authors of [25]–
[27] address the challenge of multi-operator virtual network
embedding with incomplete information, safeguarding details
related to operators’ internal topology and virtual resource
costs. Some of the above studies necessitate a central entity,
while those adopting decentralized approaches either entail the
exchange of “sensitive” information or, when partially hiding
private information, base their solutions on local optimal or
sub-optimal decisions rather than global ones.
Recent literature provides limited insights into how
blockchain technology can facilitate federations of InfSPs. The
authors of [28] and [29] introduce a generic decentralized
architecture for secure and trustworthy operations of decentral-
ized service platforms, demonstrated using cloud federation.
However, these studies, while significant in implementing
decentralized platforms, lack a comprehensive exploration of
the economic aspects and incentives of cloud federation. Also,
in [30], authors propose a model for application provisioning
using resources from multiple cloud providers, employing
coalitional game theory for resource allocation. While the
model initially requires a third-party auctioneer, the authors
suggest its potential development in a decentralized manner,
leveraging blockchain technology. This work aligns closely
with ours; however, it assumes a standalone first-price auction
mechanism, implying that the truthfulness of InfSPs is not
guaranteed. This implies potential sub-optimal solutions.
Additionally, there is some related work on implementing
sealed-bid auctions without a trusted-third party. A distributed
solution is proposed in [31] for first-price auctions, using bid
vector slicing and mixing, while only the winning bid value is
disclosed to seller. However, the bidders are restricted on the
values that they can select for their bids. Another approach
[32] uses a trusted hardware enclave and a front-end smart
contract, decrypting all bids in the enclave to determine the
winner. In [33], bidders submit homomorphic commitments to
a blockchain smart contract, revealing commitments only to
the auctioneer via secure public-key encryption, supported by
ZKPs. However, it lacks collateral support for bids. SBRAC
[34] suggests a blockchain-based approach without an auc-
tioneer, utilizing Pederson commitments and Non-Interactive
ZKPs for bid privacy and public verifiability. Winner deter-
mination involves a voting protocol among bidders. Zether
[23] is a more generic protocol for privacy in smart contracts,
which may be used for implementing sealed-bid auctions.
Bidders lock encrypted bid values to a new account linked
to the auction smart contract for bid confidentiality. In the
revelation phase, bidders submit bids and ZKPs, enabling the
auction smart contract to determine the winner and execute
value transfers.
VI. CONCLUSIONS
In this paper, we proposed innovative mechanisms and
policies for the decentralized management of InfSP federations
by means of a novel hybrid sealed-bid reverse auction. Our
solution employs a greedy two-phase algorithm for nearly
optimal resource allocation and an innovative hybrid mech-
anism for pricing of resources and distribution of the revenue,
which combines the well-established VCG and first-price
auctions with our sophisticated federation wallet management
mechanism. By putting all these together with a blockchain-
based decentralized implementation, we establish a complete
federation approach framework that possesses nice properties
such as efficiency, budget-balance, truthfulness, fairness, in-
dividual rationality, bid privacy, commitment non-repudiation,
public verifiability and trustworthiness. Extensive experiments
validate the effectiveness of our approach. Possible directions
for future work include the full implementation / deployment
of our solution in a blockchain environment and the investi-
gation of performance aspects in practice.
ACKNOWLEDGMENT
This work is supported by the IoTFeds project, co-financed
by the European Regional Development Fund of the Euro-
pean Union and Greek national funds through the Opera-
tional Program Competitiveness, Entrepreneurship and Inno-
vation, under the call RESEARCH – CREATE – INNOVATE
(project code: T2EDK-02178). This work has been partially
funded by the European Union in the framework of the NGI
TRUSTCHAIN project, grant no. 101093274.
REFERENCES
[1] R. Buyya, R. Ranjan, and R. N. Calheiros, “Intercloud: Utility-oriented
federation of cloud computing environments for scaling of application
services,” in Proc. of 10th ICA3PP, 2010.
10
[2] B. Rochwerger et al., “Reservoir-when one cloud is not enough,”
Computer, vol. 44, no. 3, pp. 44–51, 2011.
[3] D. Kim, H. Muhammad, E. Kim, S. Helal, and C. Lee, “Tosca-based and
federation-aware cloud orchestration for kubernetes container platform,”
Applied Sciences, vol. 9, no. 1, p. 191, 2019.
[4] L. Mashayekhy, M. M. Nejad, and D. Grosu, “A trust-aware mechanism
for cloud federation formation,” IEEE Trans. on Cloud Computing,
vol. 9, no. 4, pp. 1278–1292, 2021.
[5] D. Niyato, A. V. Vasilakos, and Z. Kun, “Resource and revenue sharing
with coalition formation of cloud providers: Game theoretic approach,”
in Proc. of 11th IEEE/ACM CCGRID, 2011.
[6] H. Li, C. Wu, Z. Li, and F. C. Lau, “Profit-maximizing virtual machine
trading in a federation of selfish clouds,” in IEEE INFOCOM, 2013.
[7] G. Darzanos, I. Koutsopoulos, and G. D. Stamoulis, “Cloud federations:
Economics, games and benefits,” IEEE Trans. on Networking, vol. 27,
no. 5, pp. 2111–2124, 2019.
[8] H. Roh, C. Jung, W. Lee, and D.-Z. Du, “Resource pricing game in
geo-distributed clouds,” in IEEE INFOCOM, 2013.
[9] N. Samaan, “A novel economic sharing model in a federation of selfish
cloud providers,” IEEE Trans. on Parallel and Distributed Systems,,
vol. 25, no. 1, pp. 12–21, Jan 2014.
[10] Virtuozzo, “Onapp federation,” https://docs.onapp.com/KB/federation,
accessed December 11, 2023.
[11] G. C. Computing, “Set up anthos service mesh for multiple gke
clusters using terraform,” https://cloud.google.com/blog/topics/hybrid-
cloud/how-to-federate-multiple-gke-clusters-with-anthos-service-mesh,
accessed December 11, 2023.
[12] HPE, “Cloud28+,” https://www.hpe.com/psnow/doc/a00036202enw, ac-
cessed December 11, 2023.
[13] N. Nisan and A. Ronen, “Algorithmic mechanism design,” in ACM
STOC, 1999.
[14] V. Krishna, Auction theory. Academic press, 2009.
[15] AWS, “Aws connected mobility solution,” https://aws.amazon.com/
automotive/solutions/connected-mobility/, accessed December 11, 2023.
[16] ——, “Aws iot core pricing,” https://aws.amazon.com/iot-core/pricing/,
accessed December 11, 2023.
[17] D. B. Shmoys, ´
E. Tardos, and K. Aardal, “Approximation algorithms
for facility location problems,” in ACM STOC, 1997.
[18] Gurobi, “Gurobi optimizer,” https://www.gurobi.com/solutions/
gurobi-optimizer/, accessed December 11, 2023.
[19] S. Martello and P. Toth, Knapsack problems: algorithms and computer
implementations. John Wiley & Sons, Inc., 1990.
[20] S. Nath and T. Sandholm, “Efficiency and budget balance in general
quasi-linear domains,” Games and Economic Behavior, vol. 113, pp.
673–693, 2019.
[21] S. Wang, W. Ding, J. Li, Y. Yuan, L. Ouyang, and F.-Y. Wang, “Decen-
tralized autonomous organizations: Concept, model, and applications,”
IEEE Transactions on Computational Social Systems, vol. 6, no. 5, pp.
870–878, 2019.
[22] E. Athanasakis, Z. Sakellariou, G. Darzanos, S. Polymeni, G. Spanos,
T. G. Papaioannou, K. Votis, and D. Tzovaras, “Trustworthy decentral-
ized management and governance of internet of things data federations,”
in Proc. of IEEE International Conference on Internet of Things and
Intelligence Systems 2023, 2023, pp. 247–253.
[23] B. B¨
unz, S. Agrawal, M. Zamani, and D. Boneh, “Zether: Towards
privacy in a smart contract world,” in Financial Cryptography and Data
Security, J. Bonneau and N. Heninger, Eds. Springer, 2020, pp. 423–
443.
[24] U. Fiege, A. Fiat, and A. Shamir, “Zero knowledge proofs of identity,”
in Proceedings of the nineteenth annual ACM symposium on Theory of
computing, 1987, pp. 210–217.
[25] D. Dietrich, A. Rizk, and P. Papadimitriou, “Multi-provider virtual
network embedding with limited information disclosure,” IEEE Trans.
on Network and Service Management, vol. 12, no. 2, pp. 188–201, 2015.
[26] T. Mano, T. Inoue, D. Ikarashi, K. Hamada, K. Mizutani, and O. Akashi,
“Efficient virtual network optimization across multiple domains without
revealing private information,” IEEE Trans. on Network and Service
Management, vol. 13, no. 3, pp. 477–488, 2016.
[27] G. Darzanos, I. Koutsopoulos, K. Papakonstantinopoulou, and G. D.
Stamoulis, “Economics of multi-operator network slicing,” in Proc. of
IEEE WiOpt, 2022.
[28] B. C. Ghosh, S. K. Addya, A. Satpathy, S. K. Ghosh, and S. Chakraborty,
“Towards a democratic federation for infrastructure service provision-
ing,” in Proc. of IEEE SCC, 2019.
[29] B. C. Ghosh, T. Bhartia, S. K. Addya, and S. Chakraborty, “Leveraging
public-private blockchain interoperability for closed consortium inter-
facing,” in IEEE INFOCOM, 2021.
[30] S. K. Addya, A. Satpathy, B. C. Ghosh, S. Chakraborty, S. K. Ghosh,
and S. K. Das, “Comcloud: Virtual machine coalition for multi-tier
applications over multi-cloud environments,” IEEE Trans. on Cloud
Computing, vol. 11, no. 1, pp. 956–970, 2023.
[31] S. Zheng, L. McAven, and Y. Mu, “First price sealed bid auction without
auctioneers,” in Proc. of the ACM IWCMC, 2007.
[32] H. S. Galal and A. M. Youssef, “Trustee: Full privacy preserving vickrey
auction on top of ethereum,” in Financial Cryptography and Data
Security, A. Bracciali, J. Clark, F. Pintore, P. B. Rønne, and M. Sala,
Eds. Springer, 2020, pp. 190–207.
[33] ——, “Verifiable sealed-bid auction on the ethereum blockchain,” in Fi-
nancial Cryptography and Data Security: FC International Workshops,
BITCOIN, VOTING, and WTSC. Springer-Verlag, 2018, p. 265–278.
[34] B. Chen, X. Li, T. Xiang, and P. Wang, “SBRAC: Blockchain-based
sealed-bid auction with bidding price privacy and public verifiability,”
Journal of Information Security and Applications, vol. 65, 2022.
11
